157

One reason why this might not be a good idea is that you would have to enforce unique passwords. This does not seem like a big issue to user experience at first, but from a security point of view, this is critical, here is why: Enforcing unique passwords means that when a user picks a password there is a chance they accidentally (or with malicious intent) ...


95

Call it the email address. It's unambiguous. A user returning to your service will always remember their email. They may not remember if they configured a special username, however.


93

There are a few reasons not to allow spaces in usernames... ...most of which can be resolved with proper implementation: They need to be tested with 3rd party software. Even if your software allows spaces in usernames, if you are using 3rd party software libraries to handle usernames they may disallow spaces so you will have to at minimum test compliance ...


51

This is not as simple as it may seem, and although your instinct may be to ban someone, you should first consider the following: How do you determine what is offensive or not? There are many surnames (last names or family names) that would be considered swear words in English, let alone some other cultures. So you run the very real risk of banning someone ...


41

If you choose to have a password only log in, you will run into many problems. Security If you only require a password, you have no way of knowing who it is that you are logging in unless you enforce unique passwords. In that case, if I were to sign up and tried to use a common password (say "Password") and your system told me that it was not allowed, ...


26

Since you want to indicate function in your URL:s, the best way would be to actually type out that function in the URL. My suggestion: User: dummy.com/user/johndoe Business: dummy.com/business/acmecorporation Edit: adding an excellent point made by 10MAY in another answer in this thread, regarding why you shouldn't use sub-domains: Also, sub-...


22

A reason that just providing passwords could be problematic is in system administration. By providing only passwords you are making it difficult for the administrator to get a handle on the account. Thus while each account may have an account number, the admin won't be able to easily relate that to a user. e.g. User: "I have a problem with my account" ...


20

It really all depends on your approach. These days it is easier to ask people to log in by email, which can be used as a user name and should be unique. It is sometimes hard to remember the username you have for some sites as they may differ from other sites you visit. By doing email you are ensuring it would be unique. One thing to keep in mind though is ...


19

Allowing spaces in logical "natural language like" input scenarios should not only be allowed, but encouraged. The name is not JohnDoe but John Doe. And same as one comment says (although trying to oppose to this view, so you can see it goes either way), the name is Experts Exchange, not expertsexchange and certainly not Expert Sex Change. And this is why ...


18

Neither is universally better, but you don't have to choose. Use both. It's trivial to test whether an input field is an email or a username (check whether it contains @), so you don't even need a separate field for it. Just have an Email / username field. Each has different strengths, so if you have to use one, choose what matters most to your ...


15

There are many valid reasons to limit username format. Uniqueness. If you allow multiple character sets, you can end up with names that look exactly the same, but are technically different. For example, many Cyrillic script characters look exactly the same as Latin characters but are in fact different. "Нarry" and "Harry" aren't the same word, even though ...


14

If at all possible, you should avoid truncating a unique name. Restricting usernames to a maximum length is one way of dealing with this. However, if you have some very long usernames: don't wrap the elipsis (…) to another line. This makes it appear at first glance that the full username is visible, and is likely to cause confusion. you should make sure ...


14

The goal is to make login as simple as possible for the user. Simply have two fields - one that allows them to enter either their username OR email address (labeled accordingly) and the other field for their password.


13

Interesting idea, let's analyze its parts. EDIT: I'll state outright that I'm not really a fan of the idea for the reasons kontour stated (enforcing unique passwords exposes existing passwords to new registrants). n-factor authentication As others have alluded to, the trend in security has been to increase the factors required for authentication. It's ...


13

Your question seems to assume that email senders have to either remember the email address of the intended recipient, or will have to accurately reverse-engineer the email address of the intended recipient. You also seem to assume that email addresses must be of a single form company-wide. I think that the answers over-engineer a solution because they ...


12

You shouldn't alter user input to be stored in a database. Sanitizing is common and encouraged (you'll see whitespace trimmed from the ends of a string, for example). Since you're storing the information without white space, you can never retrieve the original input, and a user may be confused if they ever see their username (in a password reset email or a ...


10

I'm willing to bet that you are more concerned with users not getting their desired nickname than the user will ever be. Right now, users have no reason to care what their nickname is on your site because it doesn't show up anywhere on your site. Because of this, I recommend not pestering your users with any obtrusive process or notification (especially a ...


10

I like the idea of guessing a name because if you guess right, the user doesn't have to enter any text. If you pick a name for the user, you are left with two possible scenarios here: The user likes the name you chose for them The user doesn't like the name you chose for them Option #2 minimizes friction for both cases and is a very clean design with a ...


10

The idea here is about simplifying the process for users by making it easier to see what available options are there and allowing them to choose instead of going by a trial by error approach where users try multiple variations of user names and find all are taken leading to additional frustration. Taking an example of signing up for yahoo mail I tried ...


10

It sounds like a misunderstanding. The UX guy has two requirements Allow whitespace in user names. On login whitespace should be ignored for convenience. If the user forgets the whitespace or puts one in, although he shouldn't, he'll still get logged in. You concluded "We'll store the username without whitespace." But you shouldn't alter the user input ...


10

having autogenerated user name is probably not good idea as they may forget it. Let them choose a username.


9

Depending on the level of experience of your users, you may wish to be careful about how you ask. If you provide input boxes for "email address" and "password" then I wonder, if maybe there is a risk of some users providing their email and password. It might also be good to give a suggestion somewhere on the page that this is a "new password for this ...


9

If you want email, use email. That said, I find that people tend to forget which email address they used to sign up. Many people have multiple email addresses. So you have to clarify what it is you're doing. Here's how I solved it:


8

One of the simplest methods that I have seen for this is to assign every user a nickname based on their UserID. So one may be "user157" and another "user18" etc. Of course most people won't like these names, which is the incentive to get them to change them. It would also help to send everyone an email letting them know that this is the case and that ...


8

One of the immediate problems is with scalability, your only ever going to be able to support 26*26 unambiguous users as an absolute maximum although this would require users with initials like QX and ZJ so in reality it will be a smaller set, even if you are global. you rule out tooltips (which are a good idea btw), however, there are some other things you ...


8

Using the word "you" should generally be reserved for descriptive texts that address the logged in user. For example, you would say "You have 1 task assigned to you" to illustrate that the user has a task pending, but in a grid of tasks and various status values, it would look more consistent to have the user's display name instead of just "you." If you ...


8

Why not use their email address as their username, like thousands of sites do? If you need them to choose a username at a later date you can provide a screen for doing so and guide them to create one and let them know where it will be used across the site, like a message board.


7

Short answer: No There are users who like obscenity and vulgarism, there are those who don't. Generally those kinds of people don't like to mix, and will always try to segregate into separate groups. If you ban offensive names (which is not that easy from technical standpoint), you remove one of the flags those people use to distinguish themselves. However ...


6

I favor using an email address and password for authentication (i.e., registration/login) rather than a username and password. There are a couple reasons for this: It's easier to remember what your email address is (assuming you typically use one email address for all sites) than to remember which username goes with which site. Email addresses are ...


6

An email field is best way to login. One more advantage is there, if I forgot password they click "reset password" to send mail for password changes. You are correct name is always duplicated for each person. Better we can have email field for login. Worst case we can allow to enter below cases: Case1: Name / Email ID (we have to do lots of query) ...


Only top voted, non community-wiki answers of a minimum length are eligible