My point is that we already have a mobile friendly UI component to display listerners, discovery etc. We should probably enable it by default and not only to list errors.
I’m also for better terms in the UI.
The listeners are actually not clickable (just checked in the code). There is a special popup for “discovery failures”, but nothing else than that. A new popup with listeners’ information with actual addresses and such would likely have to be implemented separately.
Just my meta-2-cents, ignore at will:
This seems like the kind of issue, that’s pretty simple at its core and if you can/will do it yourself, fixing it takes less time than discussing it. And if you can’t do it yourself, discussing it is pointless unless you find someone to do it.
Agree, and I might take a stab at fixing it if time permits. If someone else wants to try, just go ahead.
1 Like
I wonder whether we should display more elaborate information about discovery and listeners in a modal overlay in general. Not only in case of errors, but also the working ones, along with a very short explanation what “listener” and “discovery” even means.
I could extend and rename discoveryFailuresModalView.html to show working ones as well, then copy it to a listenersModalView.html. Or even share the same basic structure, similar to what was done for the revertOverrideView.html.
What do you think? Get rid of the tooltips or is this heading to modal dialog proliferation?
EDIT: gui: Modal dialog for listeners and discovery status. by acolomb · Pull Request #7539 · syncthing/syncthing · GitHub opened with a draft of the common status dialog.
Some ideas for new, less technical terminology:
Listeners 3/3 →
- Accepting Connections via 3/3
- Awaiting Connections on 3/3
Discovery 5/5 →
- Finding Devices via 5/5
- Discovery Mechanisms 5/5
- Discovery Methods 5/5
@Martin1 which of those would you have found least confusing / easiest to understand? (Assuming each of the counts is clickable for more details)
I think that it would be nice to have both working ones and failures included in the modal. Having a short explanation would be useful, but there is also the question of whether the same explanation should be put in the Settings under each of the respective options. Although, when it comes to the Settings, I believe that having a help link to the Docs would probably be more appropriate, but I’m not sure if all of them are even explained in the Docs (as separate entries, at least).
When it comes to renaming “listeners” and “discovery” to more friendly names - it would probably be good to make them less confusing for new users, but one problem here is that these terms are used in many different places right now, both in the GUI, and also in the Docs. If you rename them just in the main part of the GUI and leave the rest unchanged, then the context will be lost.
Actually within the GUI it is pretty well contained, if you search for “listener” or “discovery” within all HTML files. I will go through the docs when the PR is ready to merge and update there.
Having these terms in just one spot on the GUI really doesn’t help understanding what they do, so I think we can’t make it much worse. Having seen them first in a translated version (German Zuhörer), I couldn’t even make the connection what English term I should look for in the docs to understand them… I’d keep the old (technical) terms in the dialog heading, so it’s only the first glance overview where the technical context is lost.
How about simply something like
- Listening Connections
- Discovery Servers
The original terminology is kept, but with the “connections” and “servers” it makes the two more obvious, and especially in the former, the whole term “listening connections” would be much less scary than just “listeners”, as it is the case right now. Obviously, the user will still have to read up on each of them, either in the pop-up modal or in the Docs, if they want to understand the exact meaning, but still…
I don’t think “listening” makes any sense to a non-technical user. It’s mostly based on the Berkeley socket API’s listen() function. But anyone not familiar with the term might think this is some kind of smart speaker or digital assistant thing? IIRC it also includes relay connections btw.
Regarding discovery, those are not just servers, but also e.g. local LAN announcements.
It may not be the best, but at least you can search for the term and get some meaningful information. If you search for “listeners”, the first result on Google is a Japanese anime 
.
I’m not sure about discovery then, but as long as the term “discovery” itself is included, I doubt that the meaning will be any clearer for an average user anyway.
How about:
- Connection Listeners
- Discovery Mechanisms
Because we’re listening for potential connections but we might not have any yet which makes the term “Listening Connections” a bit strange.
Accepting or awaiting connections sounds fine, but if you’re looking to replace “listeners” you need a noun and not a verb, in at least some places. I’m not sure an “acceptor” or “awaiter” would be an improvement over listener.
I wouldn’t replace it everywhere, just in that one place in the overview. The intent with these suggestions is to write what it does instead of what technical term is used for the mechanism. Therefore I’m leaning toward the verb form / half sentence.
In my ears that sounds like an eavesdropper on the connection. Can’t imagine it to make sense to an uninitiated user.
How about combining the what does it do with the technical terms:
- Listeners Awaiting Connections
- Discovery Mechanisms Announced
Re-reading the docs, I noticed that the localAnnounceEnabled and globalAnnounceEnabled options actually control where our address is announced just as much as finding others.
We talk about “listening addresses” in the settings dialog. Keeping some consistency with that is probably useful, so unless we change that you might get “active listening addresses” and “active discovery mechanisms”.
I don’t see the immediate connection from “listening” to “eavesdropping”. In fact this discussion is the first I’ve heard of it in over half a decade of using the terminology. Listening is what you do when someone talks to you, after all.
2 Likes
Any objections to those suggestions from @calmh?
- Active Listening Addresses
- Active Discovery Mechanisms
I could easily live with those, although they’re still rather technical. But in some regards the current GUI is rather for technical people, not something like Dropbox with its colorful simplistic icons, hiding all the details what it actually does.
It was about “listener”, which, mentioned next to a connection (which has two ends already), sounds like a third, unrelated entity. But never mind, we don’t need to go deeper on that.
Yeah, I would say that the word “listeners” (with no additional explanation, etc.) paired with a number next to it is the scary part here.