A URL field pre-filled with a http:// which doesnt disappear on focus is bad UI | Hacker News Reader

which doesnt disappear on focus is bad UI

log.valhallaisland.com

23 pointsbarredo37 comments

No one types out URLs

An unfounded assumption. I type out URLs quite often on things like blog comments or when creating accounts on new webapps. I'm not sure why I'd go to my own Web site or Twitter page and copy/paste the URL when I can type it a lot quicker.

Further, you don't have to "delete" the existing "http:// when pasting. Just double click in the field to have all the text selected, then paste. It replaces the existing contents. Adds the time it takes to do a double click or press Ctrl/Cmd+A.

The problem with UI suggestions is that even when they're logical and seem to make sense, they won't for everybody - especially not those who've become so used to working around the problem, that a "solution" could expend more mental effort than following how everyone else does it already.

> Just double click in the field to have all the text selected, then paste.

This won't work when using the primary selection (ie. middle-click paste) in X. Selecting the text wipes out the previous selection.

I might be missing your point, but I repeated the steps I mentioned in Ubuntu and have success. No middle click pasting though, just the OS X/Windows/everyone else standard of either context menu pasting or Ctrl+V. I recorded it too: http://www.youtube.com/watch?v=nZl3gTzqyKA

What am I missing?

For unix systems with X, you copy the text by selecting it. So when you want to paste a URL, selecting the old URL to delete it will overwrite the copied URL. You would need to delete it first, and then copy the URL you are after.

Again, though, I think I'm missing something. Isn't the windowing system Ubuntu uses X? In my video demo I "select" the contents of the text box, yet the existing contents of the clipboard remains. Or is this something Ubuntu does to keep us "other platform" migrators happy?

There is another clipboard that X users like using and don't like having obliterated whenever a program requires text selection. The ctrl-C/V clipboard and the highlight/middle-click clipboards are different.

http://www.jwz.org/doc/x-cut-and-paste.html

There are actually two different buffers in X and they are each used a bit differently. See here for an explanation:

http://www.jwz.org/doc/x-cut-and-paste.html

It is a pretty safe guess that you don't use Linux.

There, selecting the text automatically copies it, so when you paste you just paste back the text you just highlighted.

Maybe it does on your flavor of Linux but I gave it a try in Ubuntu and get the expected behavior (as on OS X and Windows). I even recorded the session and put it on YouTube: http://www.youtube.com/watch?v=nZl3gTzqyKA

I used right click menu paste for the first run merely to show you what I was doing. I used Ctrl+V later on and got the same result.

Something's fishy here. At the very end you highlight the text field, but then you paste into it and something else (not what was just highlighted) goes in. The only time I have ever seen highlighting automatically get stuck into the clipboard (rather than the primary buffer) is when something like Glipper, Klipper, or Parcellite is screwing things up.

At 0:18, I Ctrl+C the word "google" as selected below. At 0:20, I paste the word "google" replacing the full URL showing in the search box. After that, I do nothing interesting beyond randomly select the URL (but I do nothing with it) - I just didn't cut the end off :-)

My:

- Firefox

- Gnome Terminal

- Dozens of Gnome Apps

- almost everything that is stock on recent distros

seem to disagree with you.

Yeah, emacs is the one app that I can think of that does copy-on-select, and I'm pretty sure even it can be configured to be more like Windows/GTK.

Just double click in the field to have all the text selected, then paste

Unless you are a certain nameless firewall manufacturer which doesn't go with convention, and mangles password fields into something like single-click-select (but only if changing the focus to them).

Then you just double click, watch it be highlighted then unhighlighted, then single click, which does nothing this time, then try to click and select and paste and realise it doesn't accept keyboard paste, only right-click-paste.

The problem with your UI suggestions is that even when they're logical and seem to make sense, they wont for every program. ;)

The problem with your UI suggestions is that even when they're logical and seem to make sense, they wont for every program. ;)

Except I didn't make any suggestions to change the UI. Instead, I'm saying leave it as it is, do it like everyone else does, and users already know how to deal with it :-) Your comment highlights exactly why I hold that belief - you've demonstrated that there are edge cases that I (and everyone else) never anticipated.

You know what is bad ui though, have an image of a ui element and make it a hyper link so that when you click on it you are taken away from the page you are reading to a page containing only the image.

I think the best thing to do is check the URL server-side. If it doesn't contain a protocol, add http://, otherwise keep the supplied protocol.

You should always check serverside, but this post is about the user experience of entering the url, not about what happens to it once sent to the server.

The letters http:// help I think, they suggest what's supposed to go in the field. A lot of people don't know what "url" means but they recognize the http://.

Good point. This is where a light gray "http://something.com/ in the background of the text field (disappears on focus) is nice.

The protocol tells the browser which port to connect to on the server. That can't be done server-side.

In this case, where you're typing the URL in a form, presumably as some sort of content management system, you're not telling your browser to go directly to the URL but rather saying 'I want to use this resource, it's at this URL'.

Before it uses that URL for anything, the server should process it, and if it's missing something like a protocol, add in a good default like http.

It never even gets to a server if it doesn't have a protocol. The browser would have no idea what to do with it. It wouldn't even know how to understand it.

Is:

  foo@bar.com

  mailto:foo@bar.com
  or
  ftp://foo@bar.com
  or
  http://foo@bar.com

Each one of those does something totally different, and all are legal.

The browser can add a default though - and it does.

It's a text field in a form. The browser doesn't need to have any ideas about what to do with it except submit it to the server.

Submit it how? Submit it where? It's obvious you know nothing about this.

Each one of those protocols works totally different. Different ports, different messages to the server, different ways of contacting the server.

And it's not a text field either. It gets broken up into multiple pieces and each piece is used in a different part of the conversation with the server. And on top of that you need to understand the format to even figure out which server to talk to.

You're talking about the address bar, probably because this issue came up big last time with regard to Google Chrome.

They're talking about input fields in forms in the contents of the page.

So, you both know what you're talking about, you just don't know what they are talking about :)

I hate to be nitpicking but the protocol, while related to the port is still a separate thing. For example, using a url of the type ftp:// is much more than just switching to port 23, even worse a url of the type file:// is not bound to a port as far as I know. Switching protocols mean the actual exhange is completely different.

You can actually use the http protocol on ports other than 80 and its actually commonly done on local development servers where anything like 8080, 8000, 8090 or many others are frquently used. In such a case the url would be something like http://myserver.com:8080/blabla where 8080 would be the port. The confusion might arise because protocols have a default port associated with them. Sorry for the explanation of something thats probably waaaay too simple for most of the readers but that comment was just so wrong for me.

Yep, you're absolutely right. I was making overly broad strokes.

This frequently bites me when using archive.org's wayback machine. I usually use it to retrieve a page that I found a link to that now appears to be down, so I almost exclusively copy/paste there, and almost always get as my first result something like, 0 pages found for http://http:/www.archive.org/index.php*

At the very least, if you are going to have that as your UI, it'd be nice if the server would notice and strip the doubled http prefix.

Alternatively: detect when a URL is pasted and remove the placeholder http:// only then. I certainly type URLs sometimes and would find it disorienting if the http:// just disappeared when I started typing.

But how would I know it's going to do that? I'm gonna delete the http:// if I've already got an http:// on the clipboard because I can't be sure it behaves unlike every other text box I'm used to using.

If it disappears on focus, it's before you start typing (or pasting).

Thanks, I'll think about it. I'm pretty sure we do add the "http:// if you forget it, but we don't strip duplicate protocols out. I can check for that as well.

"Terrible" might be a bit far, though.

... just use "placeholder" in HTML5. Problem solved.

case-by-case, angry young Padawan.

Tumblr is horrible with this. If you want to set a click-through link for a new photo post, it's usually click-[ctrl a]-backspace-[ctrl v] as a click-through link is really never typed out, but is most likely pre-existing.

You know, you can skip the backspace; pasting something with a selection will replace the selected text with whatever's on the pasteboard (at least on all the systems I've had experience with).

Not the case here.. in Chrome on Linux in /new/photo clicking the box after clicking "Set a click-through link" highlights either nothing or the last '/'.

I said you can skip the backspace, not the Ctrl-A.

Reply on news.ycombinator.com