Web-sites! Do NOT pre-populate URL fields with “http://”

Who the heck is this meant to be for?

It’s the dialogue that WordPress gives you when you want to make part of the text of your blog entry into a link.  And the URL field comes pre-populated with a fatuous “http://”.  This saves me 0.4 seconds of typing on the one occasion in 1,000,000 that I intend to type the URL by hand.  On the other 999,999 occasions, it means instead that I have to highlight and delete the unwanted text before I can paste in the URL that I’ve copied.

(To make matters worse, the poorly designed copy/paste facility in Ubuntu, inherited from X11, throws away my copied link when I highlight the fatuous “http://”, so I have to go and find it again.)

It’s not as if WordPress is alone in this bit of petty brain-damage.  It seems to be just about ubiquitous in web-forms that invite you you to enter a URL.  Who is responsible for this?  What were they thinking?  Have they ever used their own forms?  When they do, how often do they type in “http://svpow.wordpress.com/2009/05/27/sauropods-held-their-necks-erect-just-like-rabbits/” by hand?

Please, folks.  Just stop it.  It’s not big, and it’s not clever.  If I want an “http://” in my URL field, I will paste it there.  And if I am not pasting, I am capable of typing those seven characters.


22 responses to “Web-sites! Do NOT pre-populate URL fields with “http://”

  1. I guess it’s a Windows thing? IIRC it always highlights the text when you select a field, so the Ctrl-V paste would just overwrite whatever is there. (Presumably Macs do the same thing, or web designers would have seen the problem already..)

    Tangentially, it seems that every blog engine in existence assumes that every link must start with the letters http too. Try anything else and your link gets mangled. Thanks, guys!

  2. Regarding Ubuntu’s copy/paste facility, you’re probably using the one where you highlight something to “copy” and middle-click to “paste”. There’s a second mechanism that works identically to the one in Windows – ^C to copy, ^V to paste. That way you will at least not have to find your link again.

  3. WyrdestGeek

    Ah heck, that’s nothing–sometimes I’ve seen the “http://” prefix thingie as a watermark in a text entry field. I.e. It *looks* like it’s there but as soon as you try to highlight it to delete it, it vanishes.

    I think the effect some of these sites are going for is that they want to clearly identify the link field. A better approach (for them) would be to stick the “http://” off to the *left* of the field as a prompt. Then, behind the scenes, after you’ve pasted in a link, their code can briefly look at it and append “http://” if and only if it doesn’t appear to already start with /[A-Za-z0-9]+:\/\//

    But this is another one of those where you won’t be able to change it since it’s being done for the presumed benefit of “the masses”.

    But maybe you could hack your web browser with greasemonkey or something.

    And I’m kind of stunned that they still haven’t figured a good way around the problems of X11’s old clunky not-so-good copy-paste.

    Furry cows moo and decompress.

  4. How about software designers look at what people paste into the field, decide whether or not it begins with http:// and if it’s not there, add it? This allows the user to type in whatever they want or paste in whatever they don’t want to type and the server is perfectly happy.

    To extend usability further, the page could then ping the URL to be sure it returns a proper 200 OK HTTP response code (or any code at all) and then inform the user whether their URL could be reached or not. That would be a nice, firm indicator that the URL is valid. And if the other site doesn’t respond in, say, 2 seconds, ignore it and save the data anyway so as not to place any undue burden on the user.

    Sounds like a lot of work for a simple URL box, but as long as we’re talking usability and user-friendliness, I’m all for this kind of functionality.

  5. Indeed. Design fail.

    Is WordPress open source in any fashion? (ie: can I go and fix this for us?)

  6. Joey, do you know how to change Ubuntu’s copy/paste behaviour? It’s not immediately obvious to me where to find this in the mazy of twisty little options dialogues, all alike.

    WyrdestGeek, the X11 copy-paste mechanism made a lot of the sense back in the day, when we dealt primarily with text. Even now, much of my work is done in terminals and Emacs buffers, where this approach is good; but it’s horrible for web browsers, and of course more and more of our work is migrating into the browser now — Gmail is a big one for me, and WordPress for that matter. I think it’s time to change copy/paste regimes.

  7. Is a Doctor Who – Good Man Goes to War review coming soon?

  8. @Mike Taylor
    As far as I know, there is no option to change the clipboard.

    You can use the highlight->middle click mechanic to copy and paste OR the Ctrl+C -> Ctrl+V mechanic. They’re actually two separate clipboards that don’t affect each other.

  9. Jason asks, with some justification:

    Is a Doctor Who – Good Man Goes to War review coming soon?

    Yes, it is. I’ve not been able to do this yet because of a very unusual, protracted and high-intensity period of work. I’ve only had time to blog short posts, whereas doing the Good Man review needs a good three-or-four hour stretch of free time to sit down, watch it again, think coherently, and write something (hopefully) insightful. It is near the top of my Important Things To Do list; but nowhere near the top of my Urgent Things To Do list.

  10. Gareth Jones

    From memory (so don’t rely on my accuracy), X11 actually has several completely independent “clipboards” – conventionally: Primary (used for select and middle click paste), Secondary (normally unused), Clipboard (for Windows-esque Edit->Copy/Cut/Paste, C-c/C-x/C-v), and one with a weird name I can’t remember used for drag&drop. I actually quite like having both options.

    But yes, surely the only sane way of handling URL entry fields is for the software to add “http://” after entry, if a protocol isn’t already specified. Like web-browsers have been doing for about twenty years in fact…


  11. Joel:

    How about software designers look at what people paste into the field, decide whether or not it begins with http:// and if it’s not there, add it?

    That is what they already do – and it is wrong. (Hover over my anything else link in the first comment to see why.)

    I think that another way around this would be tabbing into the URL field. The text gets highlighted so you can delete it, but it is not copied to the clipboard since it was never actually selected.

    But I completely agree that it is time to rethink copy and paste. Having two different mechanisms where it is not clear whether copied text will be in one or the other or both clipboards gets confusing.

  12. This is, unfortunately, often necessary for usability. If the field doesn’t include the http:// hint, users will type in things like “reprog.wordpress.com/2011/07”, because it works in their browser and they don’t understand that it technically means something completely different, because they’ve never heard of relative URLs. The resulting broken links are so annoying that Something Has To Be Done, and defaulting to http:// is the easiest way to stop them.

    It’s probably better in practice to only accept absolute URLs, and reject or DWIM anything else, but it can be hard to convince programmers to spend effort (and reject or misinterpret valid input!) to protect users from their own ignorance. Adding a hint is a much easier sell, and can sometimes be done by the UI designer, if they’re a different person from the programmer.

  13. Arcane Sentiment, it would be just as helpful, and much less inconvenient, if the form silently added a leading “http://” to the provided URL if it doesn’t match the regular expression /^[a-z]+:/.

  14. It would certainly be helpful, but the authors of WordPress probably weren’t thinking “how can I make entering URLs easier?”; they’re more likely to have been thinking “how can I stop users from entering invalid URLs?”. From that point of view, hinting looks like a (partial) solution, and silently fixing them looks like a workaround — and an incorrect one, as people who maintain websites are probably accustomed to considering relative URLs valid input that shouldn’t be silently altered. Mistakes like this usually happen because the designers are asking the wrong question, not because they’re mistaken about the answer to the right question.

  15. Shannon Nelson

    I’m impressed someone here remembers gopher! That was the internet before Tim Berners-Lee got loose.

  16. WyrdestGeek

    Arcane Sentiment: regarding the hinting: Right but even there, IMHO a better way to hint would be to have the “http://” as label-prompt off to the left or just above the text entry field. Or if that’s too old fashioned, maybe as a watermark that goes away when you click on it. (But my personal objection to that one is it can get confusing because it *looks* like it’s text in the field so you try to delete it only to have it disappear.)

    As to silent fixes: Again, IMHO silently fixing URLs isn’t necessarily bad. And I haven’t seen (yet) any paste-a-link-here thingies where I was expected to input a relative URL.

    Insofar as silently fixing is an example of the computer program attempting to be smart, there will be sometimes when it goes awry. But silently fixing URLs, provided you’re careful in how you do it, can also be an example of a *good* programming practice. Namely the practice that your program should be flexible in what it is willing to accept as valid input. (Exceptions to this include passwords and credit card numbers.)

    Shannon Nelson: I also remember gopher (just barely). I was first introduced to the Internet in 1994 on the college mainframe. The Internet was still text on green terminals. I played on a MUD and did a bit of info retrieval with gopher, but it seemed pretty stale.

    Someone showed me Mosaic. It looked neat, but I was totally non-plused. I didn’t really get it. The person showing it to me probably didn’t either. He felt the main cool thing about it was that it transmitted data in intermittent spurts rather than one steady connection. Technically, of course, that is correct. But that’s not why web browsers took over the world.

    Furry cows moo and decompress.

  17. Arcane Sentiment suggests:

    The authors of WordPress probably weren’t thinking “how can I make entering URLs easier?”; they’re more likely to have been thinking “how can I stop users from entering invalid URLs?”.

    But that doesn’t work, as all the bad links of the form http://http://whatever on WordPress blogs show.

  18. Wrong way: Please pre-populate all e-mail-fields with an “@”!
    We all need more of these hints in order to know, what things are good for. Let’s have stickers of tires on car doors!

  19. There’s probably a record of what the WordPress authors were thinking somewhere in their bug database or svn log, but I can’t find it. Bugzilla, however, has the same behavior, and the reasons were discussed here and here: they originally wanted to fix or forbid invalid URLs, but weren’t sure they could do so correctly, and wanted to permit things that weren’t valid URLs. The author of the patch said, “i am not enthused about trying to enforce well formatted urls. i am interested in making it easy for people to do the right thing.”

    These reasons don’t really apply to WordPress, though, since users who want to use strange URLs can always ignore the editor and write their posts in HTML.

    But that doesn’t work, as all the bad links of the form http://http://whatever on WordPress blogs show.

    It doesn’t eliminate bad links, but it may reduce their frequency; at least implementors appear to think so.

    IMHO a better way to hint would be to have the “http://” as label-prompt off to the left or just above the text entry field.

    That might backfire if it led users to think they only needed to fill in the remainder of the URL.

  20. I disagree, but with a caveat. I like http:// there but there should be an event handler on paste where http://http:// is replaced with http://, as well as http://https://.

  21. The posted form should also scrub http://http://, replacing with http://, as necessary. Ultimately this is not a UI display failure, it’s a UI handling failure.

  22. I can’t agree with you, Jon. Your proposed solution is all special-cases and unexpected changes beneath your feet. Simpler is better because it’s more predictable.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s