GNOME Bugzilla – Bug 686169
Connect to server dialog box
Last modified: 2013-10-16 15:09:57 UTC
The new "Connect to server" dialog box in nautalis in gnome 3.6 removes the ability to be able to choose a protocol from a list, and to enter in a username and password via simple text boxes. instead, there is a single text box where the user needs to input a string such as: "ssh://theuser@pants.org" the previous behaviour was much more approachable, and less errorprone than the current new behaviour.
This was changed during the 3.6 development cycle, but I don't think these here are actual bugs. Entering the username using text boxes is still supported, you will be asked for your username and password after confirming the typed in URL with Enter; no need to enter it manually in the address. - asking for the username and password upfront doesn't really work well if you choose to remember your password. In that scenario, with the previous dialog you would have had to remember you saved the password for that share before, leave the username and password fields blank and cross fingers. With the new design, you are only asked for credentials when they're actually needed to perform the connection. - with the new UI the message that is displayed for a password request can have knowledge of the service it's trying to connect. In fact, backends can provide more helpful strings to the user than before if necessary (e.g. "Enter password for the share Foo on \\Bar\Baz"). We also thought the protocol list was more harmful than useful; the reason is usually instructions for how to connect to shared locations are of the kind "you can access this share by connecting to smb://192.168.100.1". Previously, you would have had to mentally re-map the protocol part of the URL to one of the choices in the combobox (that might have had a different wording), which requires some effort and technical knowledge. Finally, the removal of those additional UI controls left space for adding a history list of previously used hosts in the dialog, which mitigates the need of typing in the address every time. For these reasons, I am closing this as NOTABUG; I would welcome suggestions of how to make this even better, but I don't think flipping the old dialog back is a good idea. Please feel free to reopen if I missed anything or you don't agree with my analysis.
I very much agree with the reporter that the previous behaviour was a lot better. It may be true that for a user with very limited knowledge it's now very slightly easier to follow instructions like "you can access this share by connecting to smb://192.168.100.1". But basically everything else is made a lot more difficult. I wanted to connect to my SSH server at home and was quite baffled to find be greeted by the empty text box. Especially since there is NO help whatsoever. What prefix do I use for an SSH server? ssh:// or sftp://? Both work, as I found out, but why should I have to find this out by trial and error?. And for all the other options that were accommodated perfectly by the old dialog, there is no indication how to handle them either. How do I specify a path on the server? How do I specify a non-default port? And how do I connect as a different user? Contrary to what Cosimo wrote, I am not asked to enter a username and password. I am connected using the local username (which happens to exist on the server as well, but that's not what I want in this case).
(In reply to comment #2) > But basically everything else is made a lot more difficult. I wanted to connect > to my SSH server at home and was quite baffled to find be greeted by the empty > text box. Especially since there is NO help whatsoever. What prefix do I use > for an SSH server? ssh:// or sftp://? Both work, as I found out, but why should > I have to find this out by trial and error?. And for all the other options that > were accommodated perfectly by the old dialog, there is no indication how to > handle them either. How do I specify a path on the server? How do I specify a > non-default port? And how do I connect as a different user? Contrary to what > Cosimo wrote, I am not asked to enter a username and password. I am connected > using the local username (which happens to exist on the server as well, but > that's not what I want in this case). Non-default paths are handled normally as in any other URL. You can also just navigate to the path once connected to the server, and/or make a bookmark to the non-default path if you need to access it frequently. Non-standard ports are IMO quite a corner case, and you probably know how to add a port to an URL if you have a knowledge of what a non-standard port for a service is. Finally, it might be that the reason it's connecting with your local username is because you set it to remember those credentials in the past, or because your user has a certificate-based SSH authentication set up for that specific server. If any of these is not working properly, please file separate bugs.
*** Bug 700231 has been marked as a duplicate of this bug. ***
There have been multiple complaints about the change in Ubuntu forums and Ask Ubuntu. When a GUI is as difficult to use as CLI, that's not a good design. Please revert to the previous dialog as this bug impairs usability.
Please reopen and fix this issue. The loss of the protocol list is a clear regression in usability. There is NO indication what is an acceptable entry in the text field. How anyone can consider the new dialog as a usability improvement is beyond my comprehension.
An additional annoyance is that if the user makes a mistake and establishing the connection fails, the dialog will simply disappear. After seeing the error message (after some time), the user has to enter the whole URL again. This happens to me quite a lot, mainly because I always forget the correct way to cram the domain and user name into an SMB URL. So my approach is usually this: 1. Open an empty gedit window. 2. Enter the URL there. 3. Select "Connect to server" in Nautilus. 4. Paste the URL into the box, click "Connect". 5. Wait. 6. If an error message comes up, us Google to look up how it's done, modify the URL in gedit, and continue with step 4. If this isn't a massive loss of usability I don't know what is. Incidentally, I noticed that the new dialog looks almost exactly the same as the "Connect to Server" dialog in OS X. Could this be an example of the "if Apple does it, it can't be wrong" mindset?
(In reply to comment #7) > An additional annoyance is that if the user makes a mistake and establishing > the connection fails, the dialog will simply disappear. After seeing the error > message (after some time), the user has to enter the whole URL again. This is a very good point! The dialog should not disappear, so that the user can fix a mistake. Can you please file a new bug report for this specific issue?
(In reply to comment #8) > Can you please file a new bug report for this specific issue? Sorry, no. I don't want this specific issue with the new dialog fixed. I want the old dialog back, which was, not only in my view, superior in almost every regard. To pick up some of Cosimo's points from #1: > - asking for the username and password upfront doesn't really work well if > you choose to remember your password. In that scenario, with the previous > dialog you would have had to remember you saved the password for that share > before, leave the username and password fields blank and cross fingers. With > the new design, you are only asked for credentials when they're actually > needed to perform the connection. It's been a while since I used the old dialog, but didn't that also ask for the username and password if it needed them? If not, wouldn't it be almost trivial to add this functionality? > - with the new UI the message that is displayed for a password request can > have knowledge of the service it's trying to connect. In fact, backends can > provide more helpful strings to the user than before if necessary (e.g. > "Enter password for the share Foo on \\Bar\Baz"). I don't understand why this is supposed to have been impossible with the old dialog. In fact, I don't think I understand the problem at all: which password could the system be asking me for other than the one for the connection I'm trying to establish? > We also thought the protocol list was more harmful than useful; the reason is > usually instructions for how to connect to shared locations are of the kind > "you can access this share by connecting to smb://192.168.100.1". Previously, > you would have had to mentally re-map the protocol part of the URL to one of > the choices in the combobox (that might have had a different wording), which > requires some effort and technical knowledge. The argument works the other way round as well. Even better, I think. I don't think I've ever encountered an instruction like "you can access this share by connecting to smb://192.168.100.1". Most users will be in predominantly Windows-based environments, where an instruction will much more likely be along the lines of "The files are in share BAR on server FOO. Don't forget you have to specify the domain BAZ". The mental re-mapping in this direction (to smb://BAZ;user@FOO/BAR, or whatever it is) requires quite a lot more effort and technical knowledge, it seems to me. > Finally, the removal of those additional UI controls left space for adding a > history list of previously used hosts in the dialog, which mitigates the need > of typing in the address every time. It was always possible to create bookmarks for connections I WANTED the system to remember. > …but I don't think flipping the old dialog back is a good idea. I do, and obviously I'm not the only one. And finally, another point from #3: > Finally, it might be that the reason it's connecting with your local username > is because you set it to remember those credentials in the past, or because > your user has a certificate-based SSH authentication set up for that specific > server. That might be true. But it's not unreasonable that I want to connect as a different user now than yesterday. With the old dialog, this was absolutely straightforward. With the new one, I have to figure out how to put the username (and possibly the domain) in the URL.
(In reply to comment #9) > (In reply to comment #8) > > > Can you please file a new bug report for this specific issue? > > Sorry, no. Ok. I've filed it as bug 710278. Thanks for bringing attention to this issue.