GNOME Bugzilla – Bug 756570
gtkplacesview no longer provides guidance on address formats
Last modified: 2018-05-02 16:48:05 UTC
Prior to 3.18, the Connect to Server dialog included a hint about how to construct a server address. This read "For example: smb://foo.example.org". This is an important piece of information, since users will often not know how to construct an address. The designs for the new connect to server UI in 3.18 [1] included the hint inside the server address box. However, this part of the design was not implemented. The result is that 3.18 has lost the hint text that was included previously. [1] https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/nautilus/nautilus-next/other-locations.png
I don't like a hint text saying 'for example'. It is long, it looks out of place (to me), and it makes the actual example scroll off. Just putting the example there is bad, since it gives you the horrible webui experience where the hint text looks exactly like the thing you want to enter and you try in vain to edit it until you realize it is fake. That is why we currently have a somewhat generic hint that says what you are expected to input here ("Server Address") without veering into the 'inline docs' or 'confusing fake content' areas.
Created attachment 313270 [details] [review] gtkplacesview: use example in the server entry hint Following mockups, so an example on how to construct an address is shown as a hint.
fwiw I made a proposal patch so you can try.
(In reply to Matthias Clasen from comment #1) > I don't like a hint text saying 'for example'. It is long, it looks out of > place (to me), and it makes the actual example scroll off. I agree that "For example" is a bit too conversational. Switching to "Example: ..." would be better. If the hint text is too long, the text entry can be made wider, and we can improve the resizing behaviour. > Just putting the example there is bad, since it gives you the horrible webui > experience where the hint text looks exactly like the thing you want to > enter and you try in vain to edit it until you realize it is fake. Using placeholder text in this way is fairly standard nowadays - it's not unusual to put an example as a hint text. And I've never seen evidence of people confusing a placeholder with editable text. > That is why we currently have a somewhat generic hint that says what you are > expected to input here ("Server Address") without veering into the 'inline > docs' or 'confusing fake content' areas. I don't see why it's wrong to provide extra guidance in the UI; we do that in many places. Are you suggesting that the string is unnecessary?
Created attachment 313271 [details] screenshot How it looks.
(In reply to Allan Day from comment #4) > > Just putting the example there is bad, since it gives you the horrible webui > > experience where the hint text looks exactly like the thing you want to > > enter and you try in vain to edit it until you realize it is fake. > > Using placeholder text in this way is fairly standard nowadays - it's not > unusual to put an example as a hint text. And I've never seen evidence of > people confusing a placeholder with editable text. I've seen plenty. Ebassi had a nice link to a mozilla bug that has some enraged commentary in it. I find it really infuriating myself. See https://bugzilla.gnome.org/show_bug.cgi?id=667502
(In reply to Matthias Clasen from comment #6) ... > > Using placeholder text in this way is fairly standard nowadays - it's not > > unusual to put an example as a hint text. And I've never seen evidence of > > people confusing a placeholder with editable text. > > I've seen plenty. Ebassi had a nice link to a mozilla bug that has some > enraged commentary in it. I find it really infuriating myself. I don't see anything there that invalides the use of placeholder text, and its widespread use leads me to believe that (a) it has been tested and found to work, and (b) that by now users will have learnt to know what it is. But that discussion is a different bug. GTK+ supports placeholder text. We use it all over the place. Why not here? And to repeat the question I posed in comment 4: do you think that the string isn't needed?
*** Bug 756453 has been marked as a duplicate of this bug. ***
(In reply to Allan Day from comment #7) > (In reply to Matthias Clasen from comment #6) > ... > > > Using placeholder text in this way is fairly standard nowadays - it's not > > > unusual to put an example as a hint text. And I've never seen evidence of > > > people confusing a placeholder with editable text. > > > > I've seen plenty. Ebassi had a nice link to a mozilla bug that has some > > enraged commentary in it. I find it really infuriating myself. > > I don't see anything there that invalides the use of placeholder text, and > its widespread use leads me to believe that (a) it has been tested and found > to work, and (b) that by now users will have learnt to know what it is. > > But that discussion is a different bug. GTK+ supports placeholder text. We > use it all over the place. Why not here? > We were using placeholder text (Server Address). It is just that you are not happy with that text, and I disagree wit your proposed replacement?
(In reply to Matthias Clasen from comment #9) ... > We were using placeholder text (Server Address). That's true. > It is just that you are not > happy with that text, and It's more that I think that the address example needs to be included *somewhere*. > I disagree wit your proposed replacement? I guess so, but you know better than me!
I've spent a while trying to come up with an improved design for connect to server, that is able to solve this issue. This is the best I've been able to come up with: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/nautilus/nautilus-next/connect-to-server-wire.png This approach has a few things going for it: * The "documentation" is a bit more verbose, which is probably helpful. * You retain the address label even when the entry is focused. * The treatment for recent servers is much better - you get the popup whenever the entry is focused, and don't have to hunt for it separately.
The mockup does not include webdav which is a special case because the protocol prefix and protocol name are not the same. https://bugzilla.gnome.org/show_bug.cgi?id=756023
The mockups I linked to above have been updated, and I'm pretty happy with their current state. (In reply to lof from comment #12) > The mockup does not include webdav which is a special case because the > protocol prefix and protocol name are not the same. > > https://bugzilla.gnome.org/show_bug.cgi?id=756023 The mockups specify http/https for webdav, but the guidance could easily be changed to use dav.
Allan that looks really nice, and if #756023 is fixed and it allows users to copy webdav links directly, that makes it even less frictionless. Looking forward to 3.22. Thanks for you work!
Created attachment 326754 [details] [review] placesview: provide guidance on server addresses GtkPlacesView currently provides no example of server addresses, which may confuse users. To fix that, add a helper popover with some guidance on server addresses.
Review of attachment 326754 [details] [review]: Overall, looks good to me. Some comments below. ::: gtk/gtkplacesview.c @@ +1846,3 @@ + + gtk_popover_set_pointing_to (GTK_POPOVER (priv->server_adresses_popover), &rect); + gtk_widget_set_visible (priv->server_adresses_popover, TRUE); This function should probably not be called on_address_entry_clear_pressed anymore, since there is no clearing going on here. A slight downside with this approach to help is that it is not keyboard-accessible. You should consider adding a keybinding to open the popover. ::: gtk/ui/gtkplacesview.ui @@ +179,3 @@ + <property name="visible">True</property> + <property name="can_focus">False</property> + <property name="label" translatable="yes">afp://</property> The strings "afp://", "ftp://", "smb://", "sftp://", "ssh://" should probably not be marked as translatable. "http:// or https://" has to be (because of the 'or'), but it should probably have a comment instructing translators to leave http:// and https:// alone.
Created attachment 326818 [details] [review] placesview: provide guidance on server addresses Fixed most of the issues pointed out, thanks Matthias. Do you have any suggestion about which keybinding should be added here?
Created attachment 326855 [details] [review] placesview: follow up fixes Since the previous patch was mistakenly pushed, I'm attaching here only the diff made against Matthias' review.
Pushed. I'm leaving this bug open until we decide a keybinding for showing the help popover. Attachment 326855 [details] pushed as bb8b459 - placesview: follow up fixes
Created attachment 326871 [details] screenshot Some feedback: • There's too much vertical spacing between the first sentence and the address. This results in the two labels looking disconnected. • The content of the popover would benefit from a bit more spacing around it (just 6px extra or so). • The point of the popover doesn't accurately point at the icon. • Are the protocol prefixes actually correct? Bug 756023 indicates that dav:// is required for WebDav rather than http:// or https://.
That's really great idea, thanks that you are working on it. I have just a few comments to make it perfect: It would be good to use something like smb://example.com/foo instead of smb://foo.example.com/, because a sharename (i.e. foo) have to been specified usually. ssh is just alias for sftp, it is the same backend and same protocol, so it doesn't make much sense for me to mention it separately. dav and davs have to be used for webdav. http and https is used for web pages and doesn't work with webdav backend... ftp backend supports also ftps, which is ftp over tls. GVfs also supports nfs. So I suggest to use the following table: AppleTalk - afp WebDAV - dav or davs (SSL) File Transfer Protocol - ftp or ftps (TLS) Network File System - nfs SSH File Transfer Protocol - sftp/ssh Not all backends don't have to be installed by default, maybe would be good to check available uri schemes using: g_vfs_get_supported_uri_schemes.
(In reply to Ondrej Holy from comment #27) I agree with most things here and have updated the mockups accordingly. The main thing is that people are familiar with the terms: I'm a little uncomfortable with "SSH File Transfer Protocol" for that reason - it's always been "Secure File Transfer Protocol" for me.
Comment on attachment 313270 [details] [review] gtkplacesview: use example in the server entry hint Thanks for the review, Allan. I'm leaving this bug open while I investigate why the popover is shown slightly misaligned relative to the icon.
Created attachment 340006 [details] [review] gtkplacesview: Add example of IPv6 address in guidance Square brackets are mandatory for IPv6 addresses. Add example of IPv6 address in the guidance to make it obvious. I have some troubles to build GTK+ master right now, so it is untested. So, it may need some additional tweaks (i.e. width-chars change or so)...
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
I'll review/work on this one
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/578.