[UX] Provide an option to hide the username field on registration (and generate usernames)

docwilmot commented 8 years ago

There is a setting on the Account settings page loginoptions

But if email only is selected, the user is still presented with a field to type in a username during registration.

This issue proposes that IF a user is not allowed to sign in with her username, as this setting enforces, it does not make sense to still require a username on registration. (username could be automatically be the email itself, or generated from the email, or generated otherwise, to be decided).

And in fact it is bad for UX to do so:

Bad UX because a user will be being asked for a field which will not be required ever again and may seem therefore a waste.
Bad UX because a site manager who wishes to remove the need for a username field still has to resort to custom code when the above form select seems to suggest that this would be automatically not presented on registration.

Proposed issue again (updated): We should provide an option to hide the username field on registration, and generate usernames automatically. This will be particularly useful if a site manager selects the "Users may log in using Email address" option, pictured above.

~~PR by @docwilmot: https://github.com/backdrop/backdrop/pull/1763~~ closed ~~PR by @jenlampton https://github.com/backdrop/backdrop/pull/1856~~ closed

bd0bd commented 8 years ago

I do not see anything confusing in this. It is correct in my mind.

mikemccaffrey commented 8 years ago

It is a pretty fundamental assumption in backdrop/drupal that users have usernames, so are going to need to collect them on registration even if they are not being used for log-ins.

serundeputy commented 8 years ago

Could/should we hide the username field with states and have it default to the email address if setting is for Email address?

docwilmot commented 8 years ago

I am thinking as the unsophisticated Backdrop newbie, who doesn't have any fundamental assumptions.

My thinking then would be that if I configure my site to allow login with username only, I'll need a username, obviously, and an email to send my users their username. But if I configure for email only, it sort of implies that I don't need a username field. Why is it still necessary, and why is there still a field asking for it?

Keep in mind that I am certainly not a newbie but when I selected "Email only" for the first time ever this week, I was 100% expecting the username field to disappear and was actually confused (!) when it still showed up. I assumed then that it would probably also confuse others, especially said newbies.

Unless I am way off and just easily confused, we could either use the email address as the username and simply don't print the field, or generate a username from the email, so I'm reopening this unless its conclusive that I am.

klonos commented 8 years ago

My thinking then would be that if I configure my site to allow login with username only, I'll need a username, obviously, and an email to send my users their username. But if I configure for email only, it sort of implies that I don't need a username field. Why is it still necessary, and why is there still a field asking for it?

Big 👍 there.

Keep in mind that I am certainly not a newbie but when I selected "Email only" for the first time ever this week, I was 100% expecting the username field to disappear and was actually confused (!) when it still showed up. I assumed then that it would probably also confuse others, especially said newbies.

Same thinking here. Although not a newbie any more, I consider "my duty" to try and put myself in their shoes. That's the same reaction I'd have. I think this is a perfectly valid issue.

klonos commented 8 years ago

...I think that if username is a fundamentally necessary thing in order to set a user up, then hide and auto-generate (equal to email by default) if the setting is email only. @docwilmot ++

docwilmot commented 7 years ago

This PR hides the username field as recommended. The username is automatically set to the user's email addresss, but there are issues here:

having a username as your email exposes your email on certain displays like in the 'author' display on nodes. Core allows emails as usernames though, so I went with this. Should core allow this? Different issue though
we could instead generate a unique username. Generating this from the email only partially fixes the first point above. Maybe random usernames?
certain characters are allowed in emails but not in usernames, especially the "+" character. This issue in Drupal raised by none other than @jenlampton (with comments by @serundeputy too) fixed the "+" sign. We would need to fix this in Backdrop as without that fix, if a user uses an email with a "+" sign, he would get an error saying the "username" has invalid characters, even though he never put in (nor even knows what is) a username.

jenlampton commented 7 years ago

We would need to fix this in Backdrop

I thought we fixed this in 1.0.0?

docwilmot commented 7 years ago

apparently not:

function user_validate_name($name) {
  ...
  if (preg_match('/[^\x{80}-\x{F7} a-z0-9@_.\'-]/i', $name)) {    <======= Note no "+"

olafgrabienski commented 7 years ago

having a username as your email exposes your email on certain displays like in the 'author' display on nodes (...) Should core allow this?

At least, core shouldn't facilitate it, so we need a username in my opinion, but I don't like the idea random usernames. If a random name is displayed to refer to an author, it's kind of useless and even strange.

I'm sorry that I missed the start of the discussion. If I may comment it so late, I'd say that logging in and registering are just two different things. I see that the current behaviour might be confusing but then let's make the forms less confusing instead of dropping the username.

jenlampton commented 7 years ago

logging in and registering are just two different things

Can you recommend other suggestions as to how we can register people without a username, without dropping the username entirely? (we haven't btw, it's now just copied from the email address)

What if we just use everything before the @ in the email address, instead of the whole email address?

olafgrabienski commented 7 years ago

What if we just use everything before the @ in the email address, instead of the whole email address?

Better than random and better than the email address. But if you know the pattern you still know the address.

Can you recommend other suggestions as to how we can register people without a username, without dropping the username entirely?

Actually I wouldn't drop the username in the registration form as in my opinion the issue isn't really a problem: The seemingly discrepance between the setting "Users may log in using Email address" and the fact that users will be asked for it a during registration doesn't affect prospective users (who have no particular expectations regarding the registration process) but at most the administrator user who chose the setting. Apart from that, all users will however be able to use the email address to log in, and that is what the setting says. Maybe to avoid confusion for site administrators, we could provide a help text on the settings form, like "Users will anyway be asked for a username during registration" (in better English of course).

docwilmot commented 7 years ago

I've created https://github.com/backdrop/backdrop-issues/issues/2486 to discuss the issue of emails as usernames.

Better than random

Not completely true as far as displaying usernames is concerned. Usernames are often completely random. There is no word in any dictionary called "quiksketch" or "hellomrcat". So if we had used PHP to generate a random name and PHP came up with "quicksketch", there would be no difference to anyone but @quicksketch (I assume that name means something to him).

and better than the email address. But if you know the pattern you still know the address.

Agreed.

doesn't affect prospective users (who have no particular expectations regarding the registration process) but at most the administrator user who chose the setting

Then why dont we ask for favorite color, or waist size too? If username is not to be used, why ask for it. Thats my issue with it.

serundeputy commented 7 years ago

Maybe we should just have the top two options:

and simply remove the third option Email address if they have to have a username then it makes sense that they can login with it.

olafgrabienski commented 7 years ago

If username is not to be used, why ask for it.

Because it is used ... as you said, for instance in posts when display of Author name is enabled.

olafgrabienski commented 7 years ago

simply remove the third option 'Email address'

I like that one!

docwilmot commented 7 years ago

Because it is used ... as you said, for instance in posts when display of Author name is enabled.

😄 touche

docwilmot commented 7 years ago

Then we should probably ask for a "Display name" and an email address during registration, and generate the username for everyone.

klonos commented 7 years ago

we could instead generate a unique username. Generating this from the email only partially fixes the first point above.

What if we just use everything before the @ in the email address, instead of the whole email address?

No, we simply cannot use the part of the email minus the @domain part because then we'd end up with duplicate usernames for johndoe@example.com and johndoe@anotherexample.com for instance.

serundeputy commented 7 years ago

Just get rid of the third option; the third option does more harm than good.

jenlampton commented 7 years ago

This was a feature we added in Backdrop because it was missing in Drupal. I haven't heard a good reason to remove it, but we do have a UX problem that people may not understand what it does.

Back in the old days it was required that everyone have a username for everything. That is not the case anymore today. Many services only require an email address and a password, and by also requiring a username in Backdrop, not only does it make the software feel dated, but it decreases the number of users that will sign up. Requiring every Backdrop site to do things "the old way" would be harmful to people who only need to do things "the new way." I don't like the idea of locking people in, especially when flexibility is supposed to be one of the reasons people would choose Backdrop in the first place.

Displaying the username on posts and comments is optional. For sites that don't want to use usernames, they probably also don't want to display anything here. Instead of forcing people to do things in a way that might be contrary to their vision, why not just guide them to the correct way to architect what they want.

Here are two ideas:

If someone selects the Email only option, fall back to using email address for username, and automatically disable the display of usernames on all node types and comments (by default).
If someone selects the Email only option and does choose to display usernames in nodes ro comments, add a message to the status report, notifying them that email addresses (for user names) may be publically available.

klonos commented 7 years ago

@jenlampton perhaps what you describe could work if we are absolutely sure that there will be no other place other than node types and comments that publicly displays the username (which falls back to the email on sites that select email as the only login option if I get this right). If there is even the slightest chance of this happening, then it is a security/privacy issue.

If we decide to leave the email only login as is, then we'd need to change the label and the behavior of the "Display author and date information" checkbox under the "Display settings" vtab on content types to just "Display date information". The "Display the author picture" checkbox will need to be hidden in these cases. We'd also need to account for the "Display pictures for comment authors" checkbox in the "Comment settings" vtab.

Still though, what would a thread without any comment author names look like? I think it'd be silly.

klonos commented 7 years ago

...I think that requiring a username and explaining where it is being used and why makes more sense.

docwilmot commented 7 years ago

The question of whether emails should be used as usernames is now a different issue at https://github.com/backdrop/backdrop-issues/issues/2486. This issue is about whether the username field should still be shown when a user is registering even if "email only" is the login method. Until we decide about https://github.com/backdrop/backdrop-issues/issues/2486, if we adopt this PR, we can generate a username somehow, so lets try and separate the two issues please.

So far it seems that most of us think the username should remain in that situation. Is that an accurate assessment?

I've also created https://github.com/backdrop/backdrop-issues/issues/2489 to discuss changing the username field to "Display name".

serundeputy commented 7 years ago

Twitter, Facebook, Drupal.org, GitHub all ask for more than just your email and they all ask for some form of Name or username presumably so that they have data other than email to display with your posts. I would guess that any service you are signing up for that lets you author information of any kind would require this.

What is the use case for email only login? What problem does it solve?

@docwilmot what prompted you to try that setting? What was your use case?

docwilmot commented 7 years ago

What is the use case for email only login? What problem does it solve?

Its not my use case. Its in core. See first post image.

And note I have nothing against the username per se. Please note the issue title and first post and other posts by me. Again: if we offer an email-only login, it seems that a username shouldnt be necessary during registration if that setting is active.

As per my last post, we seem to be deciding that is not true. I'm willing to let it go if there is consensus.

serundeputy commented 7 years ago

I understand it is in core; I'm trying to identify a use case when somebody would use it.

I think the feature we added that drupal doesn't have is that you can login with either your username or your email address.

I don't know why we added the Email address only version. There must be a reason I'm trying to identify it but I can't wrap my head around it and keeping it is starting to spawn ideas that involve a lot more code.

@jenlampton do you know what the use case is for email only no username in regards to backdrop and in general to any system where the user may be publishing content?

docwilmot commented 7 years ago

Use case: I build a site with a registration page like this (lets call it docwilmotbook):

But I know my users will always be displayed as "Dr Firstname Surname MD". I have no need therefore to ask them for a username on registration or login.

jenlampton commented 7 years ago

Twitter, Facebook, Drupal.org, GitHub all ask for more than just your email

All of these examples are places where the content is tied to the user creating a sort of "community". This is one valid use case, but there lots of websites that are not community sites. It's often not important who posted the about page on a site, immagine a large site full of similar pages. Perhaps those site owners have chosen Drupal or Backdrop for all the other fantastic features! Not every site needs to be a community :)

What is the use case for email only login?

Here are four examples of sites I manage today where the site owners did not want to have a username on user accounts:

An e-commerce site where customers log in before making a purchase, and log in afterwards to get information about the things they have purchased (in this case, puppy training classes) http://www.siriuspup.com - here the username field was actually hurting sales.
A website that has lots of admins who publish content on behalf of other people, the actual "Authors" of the content (and even comments) never log in to the site: http://www.chinafile.com (granted, this is likely an edge case, but it's a use-case none the less)
A website that posts content but never displays author information on any of the content: http://www.norcalhunterjumpers.com
Another website that never shows author information on any post: http://mtc.ca.gov

Here we have a small-business, two non-profits, and a government site. A nice slice of our target audience for Backdrop :)

Still though, what would a thread without any comment author names look like? I think it'd be silly.

You are combining the two use cases, one is a site where users generate their own content and comments, and the other is one that only needs an email address + password for an account. I don't think the use-case you describe (both those things at once) exists.

serundeputy commented 7 years ago

Thanks @jenlampton how did you get around the username field for those sites; custom code?

jenlampton commented 7 years ago

how did you get around the username field for those sites

There was a contrib module for Drupal. For backdrop I chose the email-only option :)

serundeputy commented 7 years ago

but the email only option doesn't hide username from the registration form ... I thought that is what kicked this whole thing off.

olafgrabienski commented 7 years ago

So use cases are the point here. The one mentioned by @docwilmot in https://github.com/backdrop/backdrop-issues/issues/1994#issuecomment-274354035 and @jenlampton's e-commerce example work without username but collect first and last name. I guess, conceptually these sites wouldn't work well without first and last name (or, more general, a display name).

Based on the assumption that we need a display name (potentially nodes and comments, system mails with tokens like "Welcome to our website, John Doe", and probably other places), we should let the admin choose which element(s) to use as a display name. Depending of the use case of a site and of the chosen Account settings this could be the usual username or a combination of other fields provided by the registration form.

I hope it would be technically possible to choose the relevant display name fields directly in the Account settings form. If an administrator then doesn't want to provide a source for a display name, the fallback should be the username, and it shouldn't be possible to offer email only registration (while email only login is still fine).

My suggestion may sound strict, but that's for a reason, at least at the moment, because so far (a) I don't see a good way to generate display names automatically, and because (b) I'm not optimistic that we find reasonable settings in various configuration places to compensate the lack of usernames.

Meta: The discussion of the issue has become however very complex. Does anybody dare to summarize different use cases, constraints and possible solutions?

jenlampton commented 7 years ago

A new summary would be good.

conceptually these sites wouldn't work well without first and last name (or, more general, a display name).

I guess the two use cases we have are 1) sites that display some kind of name and 2) sites that don't.

Even my ecommerce site doesn't display any kind of name anywhere but on the user account page, and there the email address is suitable, as each person can only see their own page (unless they are a site admin, or a puppy trainer). The first/last information we collect on the ecommerce site is part of the reporting / credit card processing, and not needed for the website itself.

So for the second use-case, removing the username from the submitted by ... everywhere it appears is not only a reasonable assumption, but what people with that use-case usually want.

Why don't we just do that for sites that choose not to have a username? For sites that want a real name or other combination of fields, there are solutions for that in contrib.

jlfranklin commented 7 years ago

This sounds like a conversation that a site builder should have with his client, or a Web Site Steering Committee, or a development team should have among themselves. There are trade-offs to using the email as the username, many of them cited here.

Leaving the option and documenting the ramifications of using the email as the user name is my vote.

(BTW, what happens when the user changes the email address in the profile? Does the username follow suit?)

docwilmot commented 7 years ago

The discussion of the issue has become however very complex. Does anybody dare to summarize different use cases, constraints and possible solutions?

Unfortunately, it shouldnt be complex. This issue is not about emails as usernames, nor display of usernames, its just about whether we should hide the username on the registration page if the user is not allowed to login with a username!

I've updated the first post. Please let us only decide on this issue!!

jenlampton commented 7 years ago

about whether we should hide the username on the registration page if the user is not allowed to login with a username

That seems like it should be another (separate) setting.

olafgrabienski commented 7 years ago

Disclaimer: this comment is not another argument but just some information which I find useful considering how to handle a site without asking for a username.

In the project description of the Drupal module Email Registration used by @jenlampton there is an interesting approach regarding the generation of usernames:

A username is generated and assigned based on the user name part of the email address and their user ID.

On the same page, from the the tips under Installation instructions:

You will probably want to change the welcome e-mail (Administer -> User Management -> User Settings) and replace instances of the token !username with !mailto

This automatically generated username is still displayed name for posts, comments, etc. You can allow your users to change their username (...)

docwilmot commented 7 years ago

That seems like it should be another (separate) setting.

Great idea! Like so?:

login settings

The checkbox is hidden by states and only visible for "Email address" radio. We could even further have another radio list dependent on that checkbox:

Username or email address
Username
Email address
- Hide username field on registration
- Use email as username
- Generate username from email
- Generate random username

docwilmot commented 7 years ago

So I went ahead and did it: https://github.com/backdrop/backdrop/pull/1763

Dinornis commented 7 years ago

I agree that for websites where usernames are not used or needed the registration page should not be prompting the user to create a username. However, I am not sure if just hiding and auto-generating usernames is the right way to go about this.

If usernames are not necessary, why generating usernames at all? If usernames are integral part of Backdrop core, why not work on removing this requirement from core?

If there is a need to auto-generate usernames, I don't think email address should be used for this, for reasons already stated by others above and as requested in the https://github.com/backdrop/backdrop-issues/issues/2486 issue.

olafgrabienski commented 7 years ago

Thanks for the PR! Works well, here some thoughts:

(1) We really shouldn't provide the setting "Use email as username". See also the statement on the registration form which is no longer true with this PR:

The e-mail address is not made public and will only be used if you wish to receive a new password or wish to receive certain news or notifications by e-mail.

(2) If you change the Account settings, for instance from "Use email as username" to "Generate username from email", you get a mixture of 'username types'. Don't know how to handle it, but it looks kind of ugly.

(3) Usernames like "doe_1" might look ugly to the users themselves, and they might want to change it. The relevant permission which can be changed by the admin is not enabled as default for authenticated users.

(4) The email text to a new user is speaking of logging in via username even if the "Email address" option has been chosen:

After setting your password, you will be able to log in at http://example.com/user in the future using:

username: doe_1 password: Your password

(5) With the use case "Email address" there are the above mentioned and other settings (like display of usernames as email addresses in posts or emails) without sensible defaults. It would be helpful to change them dependent on the chosen use case or to give relevant hints to the admin.

jenlampton commented 7 years ago

Thanks for the review @olafgrabienski ! Your points are all sensible, but I think a few of them should be separate or follow-up issues. Things like updating the email text based on the setting, is unrelated to this issue (but a really good idea!)

olafgrabienski commented 7 years ago

If usernames are not necessary, why generating usernames at all? If usernames are integral part of Backdrop core, why not work on removing this requirement from core?

@Dinornis - I guess, usernames are necessary at the moment, and consequently we shouldn't remove them. Re 2nd question: why should we remove something that's an integral part?

Dinornis commented 7 years ago

My second question:

If usernames are integral part of Backdrop core, why not work on removing this requirement from core?

was refering to @jenlampton comment:

Back in the old days it was required that everyone have a username for everything. That is not the case anymore today. Many services only require an email address and a password, and by also requiring a username in Backdrop, not only does it make the software feel dated, but it decreases the number of users that will sign up. Requiring every Backdrop site to do things "the old way" would be harmful to people who only need to do things "the new way." I don't like the idea of locking people in, especially when flexibility is supposed to be one of the reasons people would choose Backdrop in the first place.

I understand that this is not in the scope of this PR, but it is closely linked and should be considered to come up with the right long term solutions.

olafgrabienski commented 7 years ago

You're welcome @jenlampton . Yes, we could separate some points, I agree, but it's also important to keep the whole picture in this quite controversial issue. So, at the moment I'm not sure which points to separate and which not. Most important in my opinion: don't introduce the possibility to use email addresses as username. Let's remove this option of the PR immediatly, we don't have to wait for a follow-up issue here.

Btw, I'm not sure if issue #2486 (don't allow users to use email address as username) has to do with the approach of the PR which allows a setting to use email addresses as username, or if it's otherly related, saying that end users shouldn't be allowed to do so.

jenlampton commented 7 years ago

Most important in my opinion: don't introduce the possibility to use email addresses as username.

I understand that there are use-cases where people might not want this to happen, but there are also use-cases where it is perfectly fine (intranets, for example). Or, are you just talking about doing a better job of warning people that this might be happening inadvertently? I am all in favor of that!

Dinornis commented 7 years ago

Yes, it may be okay to display email addresses on intranets. However they usually use both username and email fields. Automatically populating the Username field with email address could cause problems down the line.

It seems like not having Username as a required field would solve this issue.

quicksketch commented 7 years ago

I took a look at the PR and I'm in agreement with others here on using email as username shouldn't be allowed as an out-of-box option.

Right now we have these 3 options:

+      0 => t('Use the email address as username'),
+      1 => t('Generate a username based on the email address'),
+      2 => t('Generate a random username'),

I'm not sure we should even bother with providing options here. I would suggest that we simply make the username be user-[uid] and get rid of all the code for generating random usernames. UIDs are already unique so there's no chance of a conflict. Though there will still be a bit of special code necessary because we don't get a UID until after the user row has been inserted.

OTOH this entire problem might be kicked to contrib where all the bells and whistles can be included.

docwilmot commented 7 years ago

OTOH this entire problem might be kicked to contrib where all the bells and whistles can be included.

Agree with everything except this @quicksketch. As explained in the first post summary, and as experienced personally (see https://github.com/backdrop/backdrop-issues/issues/1994#issuecomment-230056830) I believe this is a UX weakness in core IMHO. If I only want users to sign in with email, and if Backdrop presents this as an option, it shouldnt still be asking for an unnecessary username. And I shouldnt have to hunt a module to hide the unnecessary field. This seems like a bug.

backdrop / backdrop-issues

[UX] Provide an option to hide the username field on registration (and generate usernames) #1994