Should a sentence ending with a URL terminate with a period?
Suppose my web service needs to send a password recovery e-mail message to the user. The message will contain a link (with some disposable token). Something like:
To reset your password please follow this link:
Now there's a problem. From the grammar point of view, a sentence must end with a period:
To reset your password please follow this link:
If the message is sent in plain text or if the user is unwilling to click onto the link, but wants to copy it and paste into his browser, he might accidentally include the period into the link and that might lead to an error message from the service. Technically, it will be a user error, but it will negatively affect user experience.
So which to prefer -- a slightly illiterate phrasing or additional risk of user error?
Sentences end in periods. A URL in a "clause" all on its own is not a sentence. Note that single sentence bullet points usually don't terminate in periods either.
When I have to end a sentence with a URL I put a space between the URL and the period. It may not be perfect English style, but it completely avoids the problem of the period possibly being picked up (either by the mail client on click or by the user on cut/paste).
As for me, I'd either omit (or avoid) the comma or put the link into quotes like `... follow this link: "http://example.com/recover/TOKEN".` or just use the word "this" as an anchor for the hyperlink (or replace "follow this link" it with "click here" and make "here", or the whole "click here" a hyperlink).
@Ivan, see my comment here for why "click here" is bad: http://ux.stackexchange.com/a/15249/5400 .
This definitely is not a UX issue. However, it would be perfect for the English SE site.
Actually, while English.SE may have useful things to say about punctuating around URLs, it's still a UX issue. For example, does rewriting the sentence so it doesn't end with the URL make it harder for the user to get to the link? I don't know; I'm just throwing it out there that *grammatical* solutions and *UX* solutions might not match 1:1.
If you can't win, cheat: "go visit `http://www.foo.bar/path#.`" Having a non-existing anchor is harmless AFAIK, and it doesn't matter if the client is clever enough to figure out where the URL ends.
@charles this does not belong on english.se; to be honest I'm not quite sure it is a perfect fit anywhere but I think it's an OK fit on this site. It's almost a technical copywriting question IMHO.
I think the sentiments on Quroa from Facebook's Content Strategist regarding the UX implications of 'voice' from the site are a far better answer than what is 'technically' correct, which honestly nobody cares about... http://qr.ae/1YgZs #gramRskewl
https://www.google.com. works just fine and you can use a different color for the url...
"Technically, it will be a user error [to include the period]." Not exactly. Technically, the URL could literally be `http://example.com/recover/TOKEN.`, with a a single period at the end and included in the URL proper. That would be a bad choice for a URL of course, but that would be a separate usability question.
The Microsoft Manual of Style for Technical Publications is quoted by Business Writing as suggesting:
Restructure the sentence so that the address is not at the end of the sentence.
Set off the address, like this, with no period (full stop):
Please visit my website at:
However the same site also quotes the The Chicago Manual of Style as saying:
Other punctuation marks [other than the slash] used following a URL will readily be perceived as belonging to the surrounding text. It is therefore unnecessary to omit appropriate punctuation after the URL.
I would highly recommend choosing option 1 above to remove the problem completely and also consider removing the explicit request to follow the link from the sentence - so your example becomes for example:
Don't worry, you can reset your password if you forget it.
That kind of substitution doesn't work in plain text because the link is the link and cannot be substitued with other text
@Kris - it's not ui design as much as it is simple copywriting. What's the problem with CMoS out of curiosity?
@JamesRyan that's true of course, and therefore, for plain text I'd even more recommend option 1 to remove the problem.
"Other punctuation marks..." yeah, that's a problem too: some (including StackExchange) parsers understand http://en.wikipedia.org/wiki/Tacoma,_Washington and some (including Google) truncate it by the comma.
It is not only a problem with copy/paste. If Thunderbird (among others) receives a plain text message with an URL, it will transform it to a clickable URL, including the end period, as it is valid in an URL. A number of other punctuation characters are also legal, so care must be used.
Tradition in such plain text messages is to surround the URL with < and > as kind of quotation marks (as the latter can be problematic too; depends on the algorithm of the URL detector):
You can see that in <http://example.com/foo>.
Otherwise, as said above, a little rewording can help while preserving the elegance of the sentence (sic):
You can see that in the http://example.com/foo page.
Some references for the plain text < > algorithm: http://ideas.4brad.com/node/443, http://www.ietf.org/rfc/rfc2396.txt . Since it's a semi-standard format, most URL detectors will probably handle it correctly. (grr, it's impossible to actually have the brackets show up correctly in the comments' mini-markdown)
In this specific example, the period is not really necessary. What follows the full colon need not always be a word/ phrase or some linguistic construct. It could even be an icon/ image etc.
In general though, it is always preferable to place the link either inside the sentence or behind a part of text.
Please note the use of the period (and the comma).
The first option is exactly what I thought, but those tokens can get extremely large and distract the flow of the sentence. But nobody would accidently include a special character.
You might find Grammar Girl's advice helpful:
... unless you can control exactly how the address will be rendered, it's best to leave off the terminal punctuation or rewrite the sentence so the URL doesn't come at the end.
I terminate a sentence with a period if I am writing for print. However, for online documentation, I would rephrase the sentence.
I guess it was in the late '90s that I learned that the "right" way to send a URL via e-mail (or on Usenet) is
preceding text <URL:http://www.example.com>.
I can't seem to find that reference now (does anyone know?) and I don't know whether that practice is still considered "right", or by whom.
I either do that, recast the sentence so the URL is not followed by punctuation (as Roger Attrill suggested), or put a space after the URL:
preceding text http://www.example.com .
The latter makes me cringe, but at least the period doesn't show up as part of the URL; but I prefer recasting the sentence (which sometimes means putting the URL on its own line as a blockquote).
Some people like to copy/paste addresses into their browser to ensure they're actually going to the claimed address (at least if the browser will warn about non-ASCII characters in an ASCII-looking URL). If a user agent filters out the `
`, surrounding the URL with spaces may make selection easier.
Grammar and usage aside, DNS will accept “.” at the end of domains. “.” by itself means “root” so, for example,
amazon.com.will both return the same DNS records.
To be sure:
Deleuze:~ ryan$ dig amazon.com. amazon.com +short | sort -nr | uniq -c 2 126.96.36.199 2 188.8.131.52 2 184.108.40.206
But since you’re talking about URLs at large, I’d recast the sentence. Clarity should always trump pedantry. And besides, it’s best to end sentences with words that have an impact; URLs are mere textual flotsam… end your sentences with solid stuff.
You can add a slash at the end of domain names without changing the meaning, so, for example, "http://mydomain.com" and "http://mydomain.com." are the same thing. If you have a path in the URL, though, the period is parsed as part of the path: "http://mydomain.com/" and "http://mydomain.com/." are different.
I think this type of situation is a perfect use case for quotation marks. It eliminates any ambiguity as to where the URL ends and the surrounding text begins. Quotation marks can technically be used in a URL, but they'd have to be URL/percent-encoded anyways.
This is analogous to the common use of quotation marks for use-mention distinction. All the characters—including punctuation characters—inside a URL are being referrenced as characters in a URL string, not actually being used as periods, slashes, colons, etc. So putting them in quotes makes perfect sense.
It's similar to writing:
A period (".") is used to terminate sentences.
It's very obvious that the first period isn't being used as period, but is actually mentioning the character. Likewise, the following should be clear to most readers:
To reset your password visit "http://example.com/recover/TOKEN".
Alternatively, you could just put a space between the URL and the next punctuation mark:
To reset your password visit http://example.com/recover/TOKEN .
Well, users copy the period not because they are stupid, but because they slightly abuse the text selection tool. The same abuse will lead to quotes being accidentially copied.
@sharptooth: If what you're concerned with is inaccurate selection, then your only option is to put a margin around the URL by putting it on its own line or just pad it with a space on either side. In some cases, it may be appropriate/preferable to also increase the font size for the URL. But I think if they're not stupid, they'll notice that they've copied an extra quotation mark.
Why do you need to show the user the link URL in the first place? Most users would just click the link seeing blue text.
I'd vote for avoiding showing URLs at all if possible, as they break up the flow of text. Most users now know that if they really need a URL for some reason they can right click and copy it to the clipboard; those are probably the same users who would specifically need the URL for some legitimate reason.
Everyone else just wants to reset their password and will click the link. No URL necessary.
The URL should be available because if the user is reading the message in something other than a web browser (e.g. Outlook), he will have no way of knowing where he's going before clicking, which is a security risk. Also, if the user is reading in plain text, which he might do for accessibility reasons, he'll only see "click here" and there won't be a URL he can cut and paste into a browser.
@MonicaCellio - quite right - and the HTML Techniques for Web Content Accessibility Guidelines specifically mentions this - and recommends the use of the title attribute.
Outlook can display HTML just fine. The only people reading email from programs that can't display HTML are nerds that wouldn't care whether the link is displayed as a URL or hyperlinked text.
When I hover over a "click here" link in Outlook I don't see any hint text about what the URL behind that link is, like I do in a browser. It can *display* HTML just fine, but it doesn't provide the *information* that a browser does. When you're sending email you cannot assume a browser. Heck, I could be reading in Pine for all you know; I should still be able to extract a URL without crawling through the HTML source.
The problem i see is with mobile devices text selection algorithm. Some OSs will select the url as part of the sentence, selecting all the sentence, others wont, we can't know for sure. Have you considered putting the URL in a new line to increase ease of clicking/selecting? Ex:
To reset your password please follow this link: http://example.com/recover/TOKEN