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
Set off the address, like this, with no period (full stop):
Please visit my website at:
However the same site also ...
Given the two options, I would go for the second...
However! What I would consider to be the best option is a third alternative. Something that combines information and instructions:
This format gives the user a hint of what to write and expect. It's easy to understand that example.com/europe/ ...
Do long domain names really effect user experience?
Yes, in several ways:
Long domains are difficult to remember. A shorter one tends to be more memorable. The mind can only recall 4 things at once in its working memory. Even then, the words need to make sense (and not keyboard mash).
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 < ...
Let them change their name. A woman getting married takes the last name of her husband (sometimes), and not allowing her to change her name at a website could translate into a poor experience for her.
I'm a big fan of option #1. I had to go look up my ID# here at the UX website to find I'm #5737. Out of sight, out of mind, in a good way. I don't know ...
While longer than desirable, 27 characters (including .com) is not overly excessive, but yes, long domain names do affect user experience. Some more than others.
'Power users' know how to avoid typing the address if possible.
there are going to be some users who don't have a browser with a suggestive omnibox
there are going to be users who hunt ...
If you're looking for the most SEO friendly URLs that are also human readable, then I would recommend using all lowercase, hyphenated URLs, as that is what Google recommends in their Webmaster tools documentation. However, if SEO doesn't matter for your web app (if, for instance, it all lives behind a login requirement), then you can use whatever ...
Since you want to indicate function in your URL:s, the best way would be to actually type out that function in the URL.
Edit: adding an excellent point made by 10MAY in another answer in this thread, regarding why you shouldn't use sub-domains:
I don't have much in the way of hard data to back this up, but a number of sites which host user-generated links (eg. news aggregators, Wikipedia) specifically ban shortened URLs for trust reasons. Joshua Schachter (creator of Delicious) wrote a blog post explaining some of the issues with them.
First, .co is a TLD intended for websites hosted in Colombia.
Second, users are habituated to .com. The missing m is perturbing, and many people will forget about the fact that instead of accessing a company website, they must go to a website with a Colombia-type name.
This being said, some well known companies, including Google or Twitter, reserved .co ...
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 follow the link http://example.com/...
Firstly this is really just an extension of an inherent problem with links in the first place, which is that the target doesn't need to have anything to do with the link text - even if the link text looks perfectly adequate. In fact I would suggest that a well written text link is even more likely to engage and fool the user than a shortened link which might ...
This article might be of interest to you from the site usability.gov which states that using the prefix www. would be a good visual indicator that its a website for users. To quote the article
Use the full domain name with the "www," however, on all publicity
because it clearly identifies the name as a Web site. We found that
without including "www" ...
Yes, there are a few considerations for domain names:
Is the name memorable? Could your domain name be confused with another address, such as goggle.com vs. google.com?
Is the name easy to relay? Can you tell another person the name by saying something like "penny-dash-arcade-dot-com"?
Is the name accurate to your brand? If your site is "Cheap Pens Now", ...
I just thought of an option 3, which comes in a few parts. I'm probably being excessively verbose, but I want to make sure I've covered every case :)
Only allow name changes every so often (three months should be fine to accommodate real name changes like the Jane Smith/Jane Doe examples above).
Maintain a columns in the database of the past, say... four ...
A solution to this some services have used is to have a separate username and display name. Your user name is your portal to the site; what you login as, what your URL is based on (usually), and sometimes how people find you.
Twitter is probably the most relevant solution, as they have good SEO but they do have a display name you can change. You can't ...
There are multiple benefits for the user when you have "smart url" that is descriptive and semantic. Another good reference;
Based on article, IMO these are valid arguments for having proper URL;
a domain name that is easy to remember and easy to spell
URLs that visualize the site ...
People place the most amount of trust primarily in .com, .org, and .gov and secondarily in .net. All other TLDs are subject to additional scrutiny by your users. In addition if I just know your domain, but not the TLD you are using. I'm going to guess, and I'm willing to bet most of your users will guess ".com".
.com should always be the primary ...
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.
Use the fully typed words
Don't drop the first letter off the second word just because it happens to match. Dropping the first letter of the second word implies a new one word trademark.
People usually type out the full words of things they are searching for as evidenced by this image which was captured from the DirecTV homepage...
As a window ...
If you really care about UX - validate the URL automatically.
E.g. if user types "example.com" - change it to "http://example.com".
If you want to add an ability to navigate to the URL that wasjust typed - just underline it and make it blue; the user will understand that this is a link.
download bmml source – Wireframes created with Balsamiq Mockups
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 ...
There are various reasons for this, amongst them:
Bookmarks - I love the ability to drag and drop the browser address icon to my desktop to mark an important email.
History - Looking through your history can be the quickest way to find an email you read half an hour ago. You need an encoded url to achieve this.
App versioning - when rolling out a new ...
A quite common pattern for showing all of something is to extend the category with a filter, which in your case would be something like:
That way you can use the filter in your URL to select factories in let's say Europe:
And moving down the list to a single factory, such as:
It's an extremely contentious issue whether "user" is a bad word or not. If you want to maintain any clarity I would strongly advise against calling all people in all situations 'people.' You can't get any less specific and unhelpful than that. As long as there is a distinction between people that user or have access to your service and people in general (...
It only becomes unwieldy if you need to actually interact with it. And that is not so uncommon. After all - simply the act of seeing the URL is interacting with it already!
But let's say for example I want to translate a webpage and I need to put the URL into the translation engine. Not everyone is a great copy and paste user so imagine having to type it ...
Go with the hyphenated option. It will be easier to read for the user and if you have longer names, make it easier to recall too.
eg: look at the URL for this question:
Also, avoid capitalization if possible, just to remain consistent. eg: Was the S capital or was the D capital?
One thing to remember is the concept of people being able to recall about 7 items (established by George Armitage Miller's work on memory) in their short-term memory. If your name consisted of words like: big, dull, hello, car, house; each of these is ONE item because they connect to something already existing in their mental schema/mind.
If it is ...
The most important part of the long term success of QR codes or in fact any form of 'recognition' technology will be closely aligned to the quality of the content you are directed to.
Having used these codes recently in a case study for mobile context the main issue is where I end up. Almost all the pages I'm directed to are web pages and as I'm only ...
I have a Point 3 that is similar to the Point 1, but does not expose the ID of the user (which might give away some information).
Instead, I would simply assume that a given username is, at any point in time, held by a single person. Therefore, the url can simply embed the time (or rather, date):
Then it is just ...