Great technology, bad user interface

Feature
1

Hi Authors of syncthing!

I installed it on my Android phone + desktop PC (Debian) two weeks ago and thought it is great.

Now I wanted to document and re-install (changing the sync folder on the PC) and found that the user interface needs improvement.

The problem is that the technology and functioning of it is clear when reading the doc, but not clear when “just using” it occasionally.

So I’m now going in “stupid mode”, repeating that installation as an unknowing user, purposely not watching any videos or reading any pages, and writing down what I find. I hope it is helpful.

A) The manpage

Suggestion: The manpage should mention as the second paragraph that syncthing (on Debian) runs as a daemon (background app) started by the session and is contacted via a Web-User-Interface. Just so that commandline users know where to look.

B) Adding the Phone

I’m repeating my “dumb user” actions here to show the point. I clicked on “Add remote device” and immediately selected the Device ID shown (not many hackers on my network). It was not implicitely clear to me that the device is not only added but also authenticated by this step. Obviously I did not read the two lines of text :slight_smile:

I gave it a name (“Nokia 8”).

Suggestion 1: I note that I would have expected some button to show my own QR-Code to the other device on that page!

Suggestion 2: Even better, it should have been possible to show a more sophisticated QR-Code on that page that can be scanned on the phone and that does add the PC on the phone PLUS giving the phone some authentication to add back the connection on the PC. Well, that might be too much and too confusing.

C) Not seeing the context-sensitive menu

Good that I have added the device. I expect it must show up on the other end, too - right? I check and I don’t see anything. I go under “Devices” and it’s still empty. Hm. Obviously I do not consider the + sign because it is ABOVE the tabbed lists. I expect a general menu to be there but not actions specific to a tabbed selection done below. The typical user guide goes top-down; what I select on the top affects the content below.

Suggestion 3: Please please put the action below the tabs even though it takes another line of space. What User-Interfaces would typically do is show a list of devices and another entry with a Plus sign “Add new device”.

Suggestion 4: Please add the elementary functions “Add a device” or “Add a folder” to the menu, both of them, always to be seen. That might even go directly to the QR-code-scanner.

D) The QR-code

OK, found the + button on the phone.

Hitting on + gives me a menu. It is not immediately obvious that I can enter the device ID immediately there - who would want to enter a long device ID? But it’s good.

I want to connect via QR-code. I expect that since I’ve read it in reviews. However it is not so great that on the desktop app I have to search before I find where to show the QR-Code.

So I click the symbol and the scanner starts. Great.

On the desktop, I click the Nokia 8 device that says unconnected. I expect to find a QR-Code or some info to connect. Does not work. I click on Edit. Yes - here it is: Show QR. Now I finally can connect!

Obviously I expected that selecting the long ID was just for an initial connection that was not authenticated and showing the QR-Code would then authenticate. I expected some kind of handshake then going on.

Instead, I was mistaken: I could have shown a QR-Code that is hidden under “Actions” to connect, but when I chose the long ID, the Nokia 8 was already authenticated, and the “Show QR” is intended to Show the QR-Code OF THE OTHER SIDE TO A THIRD PARTY. That “Show QR” means “Show to third party” is not very intuitive at that place.

Suggestion 5: The “Show QR” button must be renamed. It could be “Show to third party” or “Show QR of Nokia 8” or “Pass QR to friend” or some such thing. But not “Show QR”.

Suggestion 6: In the QR-Code that is shown on the “Show to third party” button, please also print the name of the device that I have given it. Nobody wants to remember or find out which device that strange long device ID actually belongs to. The device should be identified (for me) by the name I have given it, and the long Device ID should only be the technical thing that is shown with the QR-Code in case one needs to type it.

Suggestion 7: If the remote device has never been connected (perhaps you know that state since the Phone does not know the PC yet), show the ID and the QR-code both in the extended entry under the “remote devices” field under a heading of “Show my ID to connect” or so. In other words, the connection should be handled in the list under that device.

Suggestion 8: The QR-Code scanner gives a nice message to scan but it should also give a message where to find the other device’s ID: In the Actions menu under Show ID.

E) Creating the folder on the phone

Before scanning the right QR-code, I noticed that there was a notification on my phone, so I added my PC in that way.

Now I want to share the camera folder from the phone. I want to share it unidirectionally, i.e. just send the photos to the PC.

I go to folders. Again I expect a button “Add local folder” at the end of the list.

Suggestion 9: I am very scared that I might destroy something. The “Folder type” item should go on top, and it should have a big heading “Send” or “Receive” or “Send & Receive”. Not “Folder Type” - that heading should be very small.

Suggestion 10: The “folder type” MUST be settable even before the folder has been selected. I understand that some folders can only be sent due to operating system restrictions but that should be handed by a popup.

Suggestion 11: Or alternatively there could be a small text that explains things; I want to make sure I understand about send and receive BEFORE I pick a directory - it might be cleared or shared automatically, who knows?

Suggestion 12: Selecting the directory might go to the top. When connecting a device, the process is first - select the device - second - give it a name for local use. The order for the folders should be the same.

Suggestion 13: When selecting the directory, the menu on top becomes context sensitive but that is hard to grasp. (Top down, remember?) One easily gets stuck in a bad mode and does not know how to get out. Unfortunately, that sticks - Once I have switched to “Recent” in the menu above, it will always open the “Recent” mode.

Suggestion 14: If you must have the folder type below the folder selector, then at least do this: While no folder has been selected, show a heading “Neither Send Nor Receive” with an appropriate text (Please select a folder, then decide whether you want to send or receive.)

Suggestion 15: Somewhere right in there is the name of my desktop PC with a switch. I suppose that means: Share this folder with this device. Since that is a list, please put a list heading “Share with:” and indent the device names. Please put the list more to the bottom.

Suggestion 16: “Pause Folder” might also be labelled “Pause sharing” since we are in a folder specific page.

Or is the whole setting from Folder Type downwards specific to the partner device? In that case, PLEASE indicate that by some indentation or by putting the whole group in a separate box or so.

OK, I’m creating the folder for the photos

  • “Add folder”: Share typically means two-way in regular language. When I see something called “Add folder”, I want to know before: a) Is this a folder that will be sent to other devices, or a folder that will receive data from other devices, or potentially both (but to be configured)? I want to know that BEFORE I create the folder. I want to make absolutely sure that my photos that I just made will not get destroyed or some such thing. Perhaps: Add folder (to share both ways) I understand that the button may have to be short and snappy, but the dialog that comes to add the folder MUST explain that on the top! b) I want to have a PROCESS for sharing. I want to be guided.

F) Creating the folder on the PC

Initially I did not understand the process, that after the phone was set to share, the PC would show that sharing offer and would let me create the folder properly.

Here, I do not have a very specific suggestion but the process should be made more transparent.

The whole process is driven by the problem that I do not want to share a folder before I know by usage that I can set the folder not to be changed.

That is somewhat unclear during the process.

OK, I understand that some of these suggestions might seem unreasonable once one has used the program for some time. I also understand that some people just like to try out. And I understand that at the crucial point, where the folder is picked, one can adjust “Send-only”. But there might be other users having similar reservations before using the product.

So if you want to pick some of those suggestions, feel free.

Regards,

Claus

2 Likes
2

While some changes would probably be welcome to make the current UI more accessible for new and less-tech savvy users, if you implement all of those and change the interface drastically like that, it would at the same time likely confuse the hell out of the existing Syncthing users, who are used to the current UI :wink:.

3

You are right. And I don’t mean - as a newcomer - to suggest you should implement them all. However, keeping them in the back of the mind and going in the direction of a more process-driven UI that always gives a good impression “where do I stand, what’s my next step” might be a good idea.

4

Hi Claus,

welcome to the Syncthing forum. What a long first post :slight_smile:

I agree that a few words about the architecture (console / background daemon + Web UI / API for frontends) would be of value here. Feel free to suggest a wording for this, or even better open a PR on GitHub. That’s easier to track than this thread with over a dozen individual suggestions.

In Syncthing, the device identifier is also used for authentication, as it consists of a cryptographic value that cannot reasonably be forged. That’s in contrast to many other popular systems, e.g. instant messengers. I think not needing a separate “handshake” is actually easier, but maybe not what people are used to.

I don’t think that’s a good UX, as it interrupts the “process” of adding the remote device to the local configuration with a different window (QR code). If that process is not finished properly, it will have no effect. So better finish the dialogue, then call up your own QR code from the main GUI.

At least I’m confused what you mean. It may be related to the expectation that a separate mutual authentication would be needed? After the first step (adding phone on PC), “adding the PC on the phone” is all that’s needed now, there is no further “back” connection.

Showing any device that has configured your phone’s ID in the list could spam the list pretty quickly. Then you’d need a graphical distinction between devices you have “accepted” (added on phone) and the “rejected” ones (unknown, just tried to connect). The latter currently only show up as notifications on Android, or on the Web UI if you access that. Note that it can take awhile before the connection to a new device is attempted.

Sounds like a good idea to have that in the menu drawer. Sorry I can’t help with that code-wise. Hope you find someone who does :slight_smile:

The QR code you are looking for is not in any way specific to a particular remote device, but only the local device’s identification. So looking for it behind a remote’s “Edit” button is not logical. It could be made more prominent by having the “Show ID” action right beside the local device name in the header row. Easier to access than when hidden behind “Actions” and it would make the connection to the local device clearer. Maybe even make the own device’s name clickable with a QR icon beside it?

Is there any indication in Syncthing that hinted you in this direction? Or just a wrong expectation based on other experiences?

I guess the button should be moved close to the shown device ID, making clear that it is just a different representation of this piece of information, for quick and automated optical transfer. Especially when any other tab than “General” is shown, the meaning is not quite clear. Changing the label is more troublesome because all translations need updating.

It’s already there, right in the header.

Again, I think making this seem specific to a certain remote device is misleading. You can see the “Last seen” timestamp under each disconnected remote device by expaning it. But not having connected could just mean the remote is offline, not necessarily that it needs our QR code to add. And think of use cases where it is really remote, as in showing your QR code on your screen does not help the other end at all. So such a hint would cause even more confusion I suspect.

Great, so the mechanism worked and was probably easier than you had expected :wink: As for authenticating who’s trying to connect at this point, you should of course compare the device ID to some expected value that you found on the other side’s UI, possibly told by e-mail, phone, or another trusted channel if you don’t have both devices right in front of you. That point should probably be made clear in the notification.

It is actually, because just like the device ID, the folder ID is the common link. Adding a local folder can either mean you want to share new data with other devices, or you want to configure where a pre-existing remote folder will be synced to on your phone. In the latter case, the what is definitely highest priority, followed by where it should be stored locally.

Note I didn’t comment much on your app UI suggestions because I think most developers agree that the Android wrapper has much room for improvement, but is not the project’s biggest focus. Further help in maintaining it would be very welcome. For my part I just don’t have any experience in Android app development, so I just gratefully use what’s there.

If the process of adding (sharing, linking, …) folders is not quite clear and you don’t want to take a risk, you could always just make a dummy folder for testing out the various settings before letting it eat your real data.

I also think many of these concepts are much clearer if you’ve gone through the process at least once between two non-Android devices, e.g. using the Web UI on both ends.

It’s always hard to provide enough relevant information right where it’s needed, without making it as verbose as the full documentation. Even the two lines of text you mentioned at the beginning can be skipped over, which adding more explanatory text would not help against. Thanks for sharing your perspective. Any hints about pain points or concrete ideas for UI improvement are welcome. Contributions to make them a reality even more so… :slight_smile:

I intend to work on some of these smaller issues soon as time permits. Will report back here when any concrete changes are lining up.

1 Like
5

Thank you for taking these suggestions kindly. Technically, I understand your points and was aware of many of them when writing it. As I said, the technology is really very nice. I just found that the process of setting up both devices is a bit more confusing and ambiguous than it perhaps need be. Certainly once I’ve done it I am satisfied that I can select “Send only” on the phone and be safe. However, during the process, I wasn’t always sure at which point I am and what goes next.

I agree that often adding more text is not the solution - it just increases the chance of people not reading it. Yes, I’m aware that identification and authentication are both done by the same code - however I wasn’t expecting that and for my “behave dumb” post I tried to repeat the misunderstandings. Most of the post is meant as a suggestion: If you receive feedback from other (potential) users that they found the interface not perfectly clear, these might be some of the points where they take the wrong directions of thinking.

Perhaps to analyze some of the confusion: (a) I expected connecting both devices to be a process, being performed on both devices in one. Syncthing’s philosophy is that each side does their step independently from the other, at a time of convenience. Therefore I expected the own ID and the “other side selector” in the screen to connect. I understand that the own ID is technically not dependent on the connection to another machine and therefore good UX should place it in a general, other-device-independent menu. Fine, but it’s hidden a bit too well. You are right that my expectations come from instant messengers. You have to deal with the world as it is :slight_smile: (b) Yes, suggestion 2 is too confusing. Forget it. (c) Yes, the QR-code is not specific to the other device, but that’s by no means self-evident. Many apps today do a two-way authentication by scanning one QR code. Instant messengers: By scanning the QR code from the PC, I give the PC access to the phone and not the other way around. The world is confusing :slight_smile: Yes, showing the own device name prominently with a QR-code beside it would help a lot, I think! (d) Come to think of it, no, syncthing did not hint me wrong, it was my own pre-expectation that authentication would be another step. Then if it’s not a common confusion, disregard my suggestions here. (e) Yes, moving the QR-code would help. If it’s close by the other device’s name, it will be very suggestive. If you get the same feedback from others, you might still consider changing the text too. (f) It’s already there in the header: You are right, I overlooked that. (g) Suggestion 12: OK, the folder ID is the thing. However, that was some obscure string. In particular, a string chosen before I picked the directory. (“Share under this ID” as a text?) The app is a bit sparse on text, that is often nice but for the rare setup process (set up once, use 1000 times) there might be headings inbetween. I think, the confusion comes from this: You think of where the data I will receive will be stored. That’s good when creating the folder on the receiving end. But I think of the folder that is already there and that I want to share - unidirectionally! - with the other side, because I start on the sending end. Again if you get that hint from me alone it’s just my misunderstanding. If you get the hint from more people, you might consider that for unidirectional sharing the WHAT is already there (the local folder) and the WHERE (other server) and HOW (direction, folder ID) comes second. (h) As to your last comment, I am painfully aware that adding more text is often counterproductive. Like this one probably is.

Finally a suggestion for the manpage, I have tried to make the text easier and more personal but you might want to discard it and just use the last sentence to add:

Syncthing lets you share your files between two or more devices. When you create, modify, or delete a file on one machine, it will automatically be replicated by the others. You can choose whether to send in one direction only or in both.

Syncthing does not use a cloud. Your data is yours alone, and you get to choose where it is stored. Synchronization happens directly between your machines when they are online at the same time.

Syncthing runs as a background app started by you or your session, and is managed via a Web-User-Interface. You should find entries for both in your desktop application menu.

Thanks for the very nice app and best regards, Claus

1 Like
6

I made a PR to accomplish just that:

We do see similar confusion rather often, because many users think of synchronization being a thing with two ends. Syncthing is designed to work among many equally important devices, so there is neither a receiving nor a sending end (or source / target). It always syncs multilaterally, and a count of two devices is just a common special case of that. The only “unidirectional” thing is that any device can decide for itself whether to reject changes from remotes (send-only) or just neglect to communicate local changes to the other linked devices (receive-only).

If you have any idea how to get people to grasp that fundamental difference more easily, it would actually help a lot :wink:

That’s not quite clear IMO, again hitting the problem mentioned above. The number of possible “directions” is twice the number of linked devices, so talking about “both” is misleading. Overall I think the folder types stuff is too much for this man page introduction.

I proposed a slightly longer description here, feel free to comment on the PR if that would fulfil your expectations:

About your other ideas (especially regarding the Android wrapper): It would be great if you could open more focused, individual threads to discuss the remaining problems / improvements. Filtering from this thread is rather tedious, which results in less maintainer feedback I suppose.

7

Suggestion to make the own QR code easier to discover: