What are some compelling reasons to disallow spaces in usernames?

  • I'm a developer. Our UX guy is asking us to allow spaces in usernames. The caveat is that they should be allowed anywhere.

    So entering the username 'JohnDoe' is the same as 'John Doe' is the same as 'J ohn D o e'.

    The username would be stored as 'JohnDoe' and on login submission we'll strip out spaces so we can match to our stored user.

    The dev team agrees that there's something about it we don't like, but we can't really think of a compelling argument against it besides "it's not a standard practice".

    Are there things we should be aware of in doing this that maybe we're not thinking about?

    One minor problem from the user's view: If I know my user name is "John Smith" and one day in a hurry I type "Joh nSmith" and the system still logs me in fine, I might be concerned with the security of the system because from my point of view I just logged in to my account with an invalid username.

    Making sure I've understood correctly - suppose I enter my username as `Experts Exchange`, the system will silently translate it into `expertsexchange`, and the system will direct queries for a user with username `Expert Sex Change` to my account?

    Comments are not for extended discussion; this conversation has been moved to chat.

    Considering that google does this exact same thing but with dots, I'd say go along…

    @user568458 That is not a valid case. If at all this rule of having places any where is allowed, then while creating username for the second case it should throw error that username is already in use, thereby eliminating possibility of multiple accounts match.

    @GoodSp33d That's exactly what I said - any query for `Expert Sex Change` would be treated as identical to a query for `expertsexchange` or any other variation. Any username searches on `Expert Sex Change` would return "One user found" pointing to the user who inputted their username as `Experts Exchange`, attempts to create a new user would return "User already exists" matching that user, etc etc.

    @user568458 May be I understood wrong, but I thought you were talking about two accounts getting mapped to a single user after usernames were created.

  • tohster

    tohster Correct answer

    6 years ago

    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 and in the worst case create adapters to handle spaces in usernames for non-compliant libraries.

    • Browsers wrap whitespace. So if a user name is J a s o n, you may get some awkward wrapping of the username when it's rendered by a browser at the end of a line. This can be worked around by rendering spaces as non-breaking in HTML.

    • It makes usernames more difficult to parse. Most notably, for applications which allow users to be mentioned (e.g. that reply from @tohster really sucked), then parsing the mention can be difficult when spaces are involved. This can also be worked around with careful implementation (for example, Facebook allows users to be mentioned by names, including spaces).

    • Leading and trailing whitespaces need to be managed carefully. It can be difficult to distinguish between _Jason, Jason_ and Jason (replace the underlines with spaces) when a username is rendered in a browser....so that can cause problems with user spoofing or confusion. This again can be worked around by disallowing leading/trailing whitespace, or by using non-breaking spaces to ensure usernames aren't collapsed.

    • Sequential whitespace can be difficult to discern. For example, it can be hard to tell apart Jason Bourne, Jason Bourne and Jason Bourne, particularly if other users are typing in the usernames (e.g. to send a message or to mention the user). This can be worked around by disallowing sequential whitespaces, or by just livng with it.

    None of these are particular show-stopping issues, so it's just a question of whether you are willing to take the effort/cost required to handle whitespaces properly, and whether you can live with some of the visual differentiation issues with similar whitespaced usernames.

    • Although that doesn't sound compelling, I can tell you that in real life this set of complications is usually enough to cause the majority of companies to disallow usernames with spaces.

    Microsoft Windows is a notable example of large-scale software which has allowed spaces in usernames for years. That said, even Microsoft recommends against using spaces in Windows usernames, because of some of the above issues. From this MSDN document:

    Logon names can contain all other special characters, including spaces, periods, dashes, and underscores. But it's generally not a good idea to use spaces in account names.

    But in your case...

    ..your UX guy is asking you to allow spaces during input but strip them out for everything else. So the user may enter J ason Bourne but then see JasonBourne as a response once it's resolved by the server.

    While trimming leading and trailing spaces is somewhat common for username inputs (because cut-and-paste operations sometimes insert an unwanted leading or trailing whitespace), allowing spaces inside the name is a poor idea if you're just going to strip them out.

    Your UX designer may believe that this will reduce UX friction, but that is not actually true. Usernames typically don't contain spaces, so allowing users to type in an invalid input and silently removing the space is overly presumptuous for the UX. It's better to detect the interstitial space and inform the user (e.g. Usernames can't contain spaces) so they can check the username again.

    • For example, if the login input silently accepts Jason [email protected], then browser autocompletes may remember that username and continue to autofill it incorrectly in the future. It's better to just reject the invalid name and inform the user.
    • For example, if a new user attempts to sign up with the username Jason Bourne, he may be surprised and confused when he receives a message back saying that username is already taken because JasonBourne is an existing username...even though he entered a username with a space in it.

    These are all great points, many of which we've brought up. It seems like we're fighting a losing battle on this one, as the only reason he's willing to budge on the requirement is if it's going to cause problems within the functionality of the software itself. He's pretty convinced that this is good UX, and none of the developers agree with him. I think my most compelling argument from the dev perspective is that since we're using oauth, we'll have to make sure that any application in the future that uses oauth has this 'strip spaces' requirement built in. that's a lot of overhead.

    this seems like a lot of cost and effort for a UX advantage that is questionable at best and negative at worst for the reasons above. Typically (if you can quantify the development cost) it's the product owner and not the UX guy who needs to make the call since it's a cost-benefit issue and not a hard UX issue (ie it doesn't affect hard UX constraints like safety or legal compliance). Perhaps you can have the product manager or owner mediate the tradeoff, but I'm now officially commenting well outside the scope of this question :-)

    @michael maybe it will be enough to satisfy your UX guy to place a js in the username field that ignores keyCode 32? That seems like the less unobstrusive way to 'fix' it. I would **not** such change to the backend or oauth **at all**.

    This is a good list of hints for implementation, but I can't really see the UX based arguments against it. You provided workarounds for most problems. By the way, you just need to tell the user that the name is unavailable for registration, not how it's written.

    If you're using email addresses as usernames, I have bad news for you. Spaces _are_ allowed in an email name, provided they're double quoted. Wihle `Jason [email protected]` is not valid, `"Jason Bourne"@gmail.com` _is_ valid. So now you have to store quotation marks as well...

    @ChristianStrempfer the OP has said in his comments that he needs a "programming" reason as to why it shouldn't be done.

    hi @MichaelHampton while technically allowed by RFC53XX, spaces are widely unsupported in email addresses in real life. For example, Facebook, Amazon.com, Gmail, Outlook.com, Pinterest, Microsoft, and a wide range of websites do not support spaces in email names, so for UX purposes (this site's scope) it's generally fine not to provide support.

    Now you're tempting me to create a new email account with a space in it and go on a rampage...

    @MichaelHampton *unleash h e l l !*

    @gnack That would make it off-topic, therefore we should stick to UX. (This is a good answer, I just don't see why tohster jumps to the conclusion "it's really bad" instead of "it's a very small advantage, which isn't worth the effort").

    +1 for a great list of reasons - What about the case where a user only enters spaces as their name? Then it wouldn't show up in the UI.

    hi @ChristianStrempfer if it helps, I don't think it's really particularly good or bad to use spaces. The question asks for reasons *not* to use spaces, so the answer is accordingly constructed. If the OP asked for pros and cons, or for reasons to do it, it would elicit a different answer (for a different question).

    The fix for sequential spaces is easy--collapse extras. I don't really think Jason Bourne should be distinct from Jason Bourne--that's just asking for confusion.

    Non-breaking spaces seem like a worse cure than the disease: now copy-paste becomes broken!

    The auto-complete argument is crushing. Just for that I wouldn't allow it.

    @AlbertLang if someone entered only spaces for their username, then they didn't enter a username. As the OP said, the usernames would be conflated. This is no different than normalizing the case of user input before querying (which is basically the norm for most log in systems, lowercasing it all).

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM

Tags used