Well, we currently don’t really label a connection as good or bad. I believe the most firm words we currently use is that a certain type of connection is considered ‘suboptimal in most cases’, which may or may not be out-dated. Otherwise it simply states what the type is. No value or quality-label attached to it.
As I understand, the confusion starts because we all are quite used to seeing the ‘signal’-icon as WiFi/connection-strength indicator, where less bars is of course worse than more bars.
But that is not the case here. There is some correlation between the connection type and global/default preferability, which is the base of the signal-icon-level of choice. But in the end this preferability does depend on personal use-cases and situations. There are use-cases to think of where each and every type is considered optimal. I don’t think we can handle this in a very realistic way and if so, this lies beyond the scope of this icon or related issue.
For any advanced user in specific situations these connection-type-icons may not mean very much regardless of which ones we use, or at the very least a different icon (for example level-2 instead of 5) will be the optimal one. And we also should not pretend like this icon will do more than it is supposed to. All the information which this icon is supposed to represent was already available in the details-pane, this icon exists merely for convenience - to quickly see the used connection per remote device without having to fold open the details-pane.
And for all this, different icons may be preferable. But if so, I have yet to see a suggestion with a significant improvement without making it more unclear in a different area.
Whether we need to separate QUIC is a good point. I’m not sure if it adds much, but there was some consensus about this before.
Probably QUIC (the implementation we use) is getting better and better so the difference compared to TCP under favourable circumstances gets smaller. There are of course circumstances where QUIC will perform better than TCP, and there are also things we could do to use QUIC better. For most cases it’s probably about equivalent to TCP.
I agree with this summary.
I don’t particularly care whether we indicate the results with number of stars, WiFi connectivity icons, or funny emojis. Enough other people care about it that I’m sure the decision gets well cared for
Shouldn’t we take a step back maybe?
This is a prominent UI change. I don’t think you will ever be able to make a prominent UI change without someone (or a few someones) disliking it. They are also more likely to voice that than everyone that’s just fine with it. So:
Is there actually a fundamental issue with the currently used icons?
That’s should also be discerned from the need or not for the quic-tcp-distinction and similar - that’s an orthogonal concern.
My opinion is the bars are perfectly fine. Just because they have one prominent use (cell reception) doesn’t mean they can’t be used in any other way. That’s not to say there may not be better icons, but none of the ones seen so far seem better to me. Nor do I see it as pressing to replace the bars - which obviously is just my 2c.
I cannot tell if that’s fundamental enough, but I believe that the current design is too misleading, and in several ways at that. People who don’t know the reasoning behind those icons, will draw completely incorrect conclusions after seeing these bars.
Particularly, 1) that one bar normally means the device has barely any connectivity, while in our case it just means the relay connection, which is perfectly fine and stable and normally not even too slow; and 2) that WAN/LAN connections are drastically, several times better than relay or QUIC, which is obviously very far from the truth.
I do like the topic-starter’s approach with neutral icons. They are recognizable enough, so that even non-tech persons should be able to get a general idea. And they do not imply that relay connection is almost the same as no connection at all, which the bars seem to designate.
In fact we are not indicating different levels of connection quality (as in speed), but rather all we know is the network distance. That’s why the summary by @bt90 is spot on.
LAN (as we currently identify it by private IP ranges) is close because no router can be involved (of course there are rare special cases where this is untrue). We could actually try to get this more precisely by comparing source and destination IP (where to get netmask?) or even fancy hops counting like the traceroute algorithm does…
WAN implies by its definition a wider area, thus greater distance. Routers are involved, usually varying (and slower because of aggregation) links. But it’s still all on the network transport layer.
Relays in contrast work on the application layer. For most users (do we have stats?) the relays are from the public pool, thus two WAN level links are involved, plus the relay itself. Even for the rare case of local relays, it’s more effort than a direct connection. People brave enough to run their own relay server should be competent enough to know or tell their users that one bar is perfectly fine.
So technically, the “good” to “bad” scale is definitely correct, if the criterion is defined as the distance / involved hops in between. To represent varying distance in icons, I could only think of something like concentric circles. But that would be harder to explain, though technically correct.
In the end I think the bars are fine. The ranking has an actual, non-arbitrary meaning and it’s easiest to grasp that with this well-known icon scale. Special cases are always special and should accept if the display doesn’t match their own ranking because their ranking is somehow flipped. Confused users can ask for help if it’s really bothering them and it’s quite easy to explain.
In my opinion the bars are fine. (As are clouds, circles, numbers or labels imo.) I do agree however that they can be puzzling.
For that reason I believe originally a tooltip was intended in #8553, although it doesn’t display on my machine. Perhaps the tooltip can be (fixed and) expanded to show the full ‘legend’ for clarity:
Connection type: WAN
Disconnected Relay Quic WAN << LAN
(PS - The bars-icons are not on the emoji keyboard. These icons are for demonstration purposes only.)
Seeing the icons in a legend on hover tooltip explains the user exactly what they need to know about 2 to 10 seconds after wondering what this all means.
Between setting up protocol listen addresses, toggling NAT and Relaying, I think it’s fair to assume that people installing Syncthing tend to be above average technical. The terms WAN and LAN are written on the router. Most households have one person that was instructed to “connect the modem to the WAN port” (and the NAS to the LAN port). If we choose to assume a target audience that doesn’t know this jargon, Syncthing may have bigger issues.
Tooltip in this case is problematic, because the icon is essentially a part of yet another interactive element. This makes the tooltip show, e.g. when you want to just click the device title to open the details, which I personally find annoying and not the best in terms of user experience and aesthetics (on a side note, the same applies to the similar tooltips that show folder IDs in the folder list).
Edit:
If I remember correctly, the conclusion was to move the information from the tooltip to the newly added “Connection Type” entry in the unfolded device info, making the tooltip itself redundant. Is what’s shown there not enough?
I really can’t agree with this. I’ve myself installed and helped set Syncthing up for many people whose knowledge about computers is minimal. While the initial configuration was indeed done by myself, they do continue to manage it on their own. For those users, showing too much technical information on the main screen in the GUI can make things confusing very quickly.
Also, while on the desktop it does seem that Syncthing is used mostly by technical people and power users, there also appear to be many who install Syncthing on Android with no technical background, simply by finding it in the store when they search for a file sync tool.
In the end, I just believe that there needs to be a good balance between technicalities and user friendliness here .
That relates to speed (of a transfer?) while, as shown above, the quality metric we define the ranking over is actually network distance and not necessarily (though typically) related to speed.
Yes, you’re right André, sorry, I didn’t read the whole thread.
So, as using colors seems to be an issue for some, what about a number of stars like for hotels (4, or 5 to distinguish TCP vs UDP if this ever makes sense, the first one meaning disconnected being a broken star). Or a text-only quality ratio e.g. 3/5. Or either, keeping the current indicator design, although rotated 90°, a vertical scale, but all bars being of same length*…and keeping the current idea of small dashes showing all available steps.
I try ascii art below for the later:
-
-
-
-XXXXXX
-XXXXXX
Some kind of digital VU-meter
A generic tooltip would say something like ‘Overall connection quality, not throughput related’ to prevent forum spam requesting the meaning
* this would prevent confusion with wifi/cellular bars, which are also looked as throughput quality… while they actually are not.
Not any better than the current bars though IMHO. It would raise many more questions because of the uncommon pictograms. If I had to guess without further info, I’d associate this with the disk usage on the remote device.
WAN
Disconnected
Relay
Quic
LAN
.
