Closed (fixed)
Project:
Drupal core
Version:
6.x-dev
Component:
user.module
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
21 Apr 2006 at 03:13 UTC
Updated:
6 Oct 2007 at 18:05 UTC
People seemed to like this change on the devel discussion list so I rolled it into a patch. Does the following:
1) Makes language welcome e-mails sent to new users more user-friendly by making explanations more thorough and less jargon laden.
2) Uses plain text formatting to break the email into understandable sections
3) Improves code maintenance by factoring out common welcome e-mail strings and placing them into a single new function.
| Comment | File | Size | Author |
|---|---|---|---|
| welcome_email.patch | 7.25 KB | Steve Dondley |
Comments
Comment #1
killes@www.drop.org commentedI've asked Steven Peck to review this.
Comment #2
Steve Dondley commentedKilles, any luck getting him to look at this?
Comment #3
Steve Dondley commentedBump. Maybe this can get some more attention now that 4.7 is out the door.
Comment #4
drumm- All new and modified string should have single spaces between sentances.
- The new text is not editable like the other strings.
- Distributed authentication is hard-coded in even though the drupal module might not be present.
- I think the secure password tips would be best if they were next to the password field itself.
- I think it could be less wordy and more clear.
Comment #5
Steve Dondley commented- All new and modified string should have single spaces between sentances.
Will fix.
- The new text is not editable like the other strings.
Can you expound on this? What is the "new" text and what do you mean by "editable" and "other strings"?
- Distributed authentication is hard-coded in even though the drupal module might not be present.
I decided to leave it hard-coded as before for the reason that the module may be enabled in the future. This is why I created the following language in the e-mail:
"IMPORTANT NOTE: In order to work, the distributed authorization feature must be enabled by both this site and the site your are trying to log into. If you are having problems getting this feature to work, it's likely that either this site or the site you are trying to log into has this feature disabled."
- I think the secure password tips would be best if they were next to the password field itself.
I'd rather they be left at the bottom. Such tips will only get in the way of more seasoned users.
- I think it could be less wordy and more clear.
Rather than guessing at where I might be wordy or unclear, can you site some specific examples of language that you think needs improvement?
Comment #6
Zen commentedWon't the majority of this information be better off in a page upon first login? Or perhaps a help page that is always accessible to users. IMO, these longwinded e-mails are impractical. Seasoned or unseasoned, this is way too much information to digest and most users will not bother reading beyond the "click here to log in" bit.
The welcome e-mail could perhaps be a configurable option on the settings page?
Thanks,
-K
Comment #7
Zen commentedComment #8
Steve Dondley commentedZen,
The email is long, but it is sectioned off with headings so users can quickly assess what is important and what is not. I'm curious to know if you applied the patch and looked at the resultant e-mail or whether you are basing your judgement on the long, unreadable string in the patch. There was a lot more positive response to this email when you could actuall see it. See http://lists.drupal.org/archives/development/2006-04/msg00272.html
The email that is sent is already completely configurable. If administrators don't want it to be so long, they can edit it as they'd like.
Comment #9
Zen commentedHi :)
Ah, I remembered seeing the configuration screens, but couldn't find it :/ It's under settings/user (and is certainly a lot of textareas) :| Thanks :) That makes things easier.
Yes, I did see the preview on the mailing list. I still find it long-winded. May I ask what you find lacking in the current version?
Patch review:
-Redundancies: Why the "log in later" section? Most sites have a login form on the front page.
-Marketing jargon: "Don't panic".. ", "these easy steps"..
-Password tips: I think what Drumm means is that a succinct version should probably be in the #description of the edit/reg form password fields. It's rather pointless here and just chews up space.
-Thank you: is in the wrong place. It should be at the top as it is in the current welcome e-mail.
-Generally too wordy.
-Usage of Caps :/ The asterisks and underscores should also probably use str_repeat.
-Patch generally assumes that the user is something of a blind idiot.
All in all, I just don't like it. I can see where such a welcome e-mail might be appropriate, but I really do not believe that this should be the default e-mail on all Drupal installations. I think the present version is clean, professional and to the point. The "Drupal ID" bit could probably use some additional information and should (as Drumm has stated) depend on whether the Drupal module is enabled. It might also be good to add a link to the contact page (with appropriate checks) where the user can get more help.
Thanks,
-K
Comment #10
Steve Dondley commentedZen, thanks for taking the time to comment.
What's lacking in the current version? If you put yourself in the shoes of a brand new Drupal user or a newbie to online communities (a category I'd say is probably at least 50% of the Interent population), there's plenty. Here is the current email with my comments indicated with //SD:
%username,
Thank you for registering at %site. You may now log in to %login_uri using the following username and password:
//SD The login url should come before the username an password in the e-mail. Otherwise, a lot of people are just going to see the username and password here first and then immediately go to the site and put themselves through a lot of needless hassle.
username: %username //SD Newbies and even some seasoned people may not know that you can put spaces in user names. I put text here to make that clear.
password: %password
You may also log in by clicking on this link or copying and pasting it in your browser:
%login_url
This is a one-time login, so it can be used only once.
//SD "one-time log in" is meaningless to newbies. Also, a newbie may try to click the link a second time. I added clearer language: "IMPORTANT: The link above expires after the first time you use it. Trying to use this link to log in a second time will not work."
After logging in, you will be redirected to %edit_uri so you can change your password.
//SD "redirected" is jargon. Besides, the user never notices the redirection, they just see the page when the click the link. Also, the need for a user to create a new password is not stressed enough. Most people will not bother to change their password. I made it more clear that they should do this. This will reduce hassle on administrators who will inevitably get pestered by morons who complain about passwords they can't remember and can't figure out how to get a new one. Here's my text: "The link above will take you to %edit_uri. We highly recommend changing your password here to one that you can remember. Simply type in your new password twice into the \"Password\" fields provided on the form and then click \"Submit\" at the very bottom of the page."
Your new %site membership also enables to you to login to other Drupal powered websites (e.g. http://drupal.org/) without registering. Just use the following Drupal ID and password:
//SD Drupal? WTF is Drupal? No normal human knows what Drupal is. I added some additional language that makes this clear. I added a "USING YOUR USERNAME AND PASSWORD WITH OTHER SITES" section toward the bottom of the e-mail to address this.
//SD I added an "EDIT YOUR ACCOUNT SETTINGS" section to encourage people to fill out their profile and other information. Too often, people blow this off but it's an important part of building a community. Here it is: "Other settings are available at %edit_uri that allow you to contol your identity and how you interact with our online community. To help establish yourself, we strongly encourage you to look over these options and change them as you see fit. You can always change them later at any time."
//SD I also added a "HOW TO LOG IN LATER" section. Yes, this part if basically for unmotivated user (Some may prefer to call them "morons" but I like "unmotivated" better because there are going to be a lot of unmotivated people who aren't really all that interested in thinking too hard about how to figure out how to use a site. If the answer is not obvious to them and spelled out carefully, they leave.) but it is here for completeness. It does not make sense to have an e-mail with all your log in information that doesn't tell you where on the site you can log in for future reference. I agree I can trim this down.
//SD "FORGOT YOUR USERNAME OR PASSWORD?" section was added to prevent site admins from getting pestered (and again to help unmotivated users). Yes, that could probably be shortened up, too.
//SD As far as the "Thank You" being at the top, if you look at the patch, you will see it is already there.
Comment #11
Steve Dondley commentedZen,
On usage of caps. I don't agree that this is ALWAYS bad. I think that tends to be a knee jerk reaction. Used sparingly, I think it can be used to good effect. But I don't really care one way or the other.
The original opposition to use of all caps came to people who just typed long messages in ALL CAPS LIKE THIS AND IT MADE IT DIFFICULT TO READ LONG BLOCKS OF TEXT.
Comment #12
Steve Dondley commentedHere is a greatly condensed version which I will roll into a patch if wanted:
%username,
Thank you for registering at %site. Log in now by going here:
%login_url
Once there, we highly recommend:
1) Changing your password to one that you can remember.
2) Editing your account settings to let you contol your online identity.
After this initial log in, the link above will no longer work and you will be required to log in with your username and password, currently set to:
username: \"%username\" (no quotes, with spaces, if any)
password: %password
Log in page: %login_uri
FORGOTTEN PASSWORD?
=====================
Visit %login_uri and following the instructions on the \"request new password\" link to assign yourself a new password.
USING YOUR USERNAME AND PASSWORD ON OTHER SITES
=================================================
Our site is powered by software called \"Drupal.\" It may possible to use your username and password for this site on other Drupal sites. This saves you the hassle of having to get a new username and password for every Drupal site you visit.
Your username for logging into other sites is:
%username@%uri_brief
IMPORTANT NOTE: In order to work, this feature must be enabled by both this site and the site your are trying to log into. If you are having problems logging into another Drupal site, it's likely that either this site or the site you are trying to log into has this feature disabled.
Welcome to our community!
-- %site team
Comment #13
dwwzen mentioned this in IRC and i'm curious about the outcome. i'll review everything discussed here another day when i have a chance. mostly just posting so i can track this. nothing to see here, move along... ;)
Comment #14
dwwacutally, i do already have something useful to say about this. the #1 confusion of users on my in-production drupal site (which requires admin approval) is they got the original email as soon as they registered it told them about a username and password, they tried it, it failed, they got all flustered and sent me confused/angry emails saying "your site doesn't work, i can't log in". we should rethink all of thi. there's a temporary hack, the (user_status module, which i maintain, but it's contrib, and sort of clumsy (not my code originally, and i haven't had a chance to give it the proper attention).
i think the full-blown "welcome to the site, here's how to log in, blah, blah, blah..." (for whatever values of "blah" we decide on), should only be sent once the account is active. if the site has open registration, then that's as soon as they register. if it requires admin approval, they should just get an initial message saying something like:
"Thank you for registering at [site]. Your request is pending administrator approval. Once your account has been activated, you will receive another e-mail with detailed instructions on how to login."
no matter how well-written the intro is (long or short, formatted or not, etc), so long as the user is given a temporary password or a 1-time login link before their account has been activated, they will try to use it, it won't work, and they'll be confused/angry. this seems like the main thing to fix, IMHO.
-derek
p.s. see also #57993 for more fall-out from this problem.
Comment #15
lanesharon commentedI think there shouldn't be a temporary login at all. Why can't the user register with a password. Then the email can simply say that this site either does, or does not require administrator approval. If the site does, then they will need to wait for a second email from the administrator that lets them know their account is approved. I used the user_status module and it has helped me to work through some of the 'wrinkles' caused by the temporary password situation.
It is extremely confusing to my users. You have a user status code. Seems to me that the temporary password is a redundant process.
Comment #16
dwwi believe there's a contrib module, logintoboggan (http://drupal.org/node/34309), that allows this kind of behavior. however, i can see why sites don't want it (i'd certainly never use it on any of my sites): if people could just sign someone *else* up via entering their email address and putting in a password, then they could sign up people against their will, start spamming them via their contact tab, impersonate them, etc, etc. by sending email with the secret login info, we can authenticate that the person creating the account at least has access to the email address being used. i refer you to my previous comments about *when* they should get this secret info. ;)
Comment #17
lanesharon commentedI am confused by your comments, so I have to respond in detail.
Unless I am physically resident when someone registers, I cannot validate that they are not impersonating someone.
If I have administrator approval required on my drupal site, the registration process would certainly allow for input of a password. And if I do not have administrator approval, then most likely I have an open user site anyway, so verifying authenticity is unnecessary.
I have administrator approval required. Under the current system, someone registers on my site. They enter a username and profile info. Their user record and profile record is created and the status (on the user record) is set to 0 (not active). A welcome letter is sent out, with the temporary code. If the email address is invalid, I will get an email kickback and know that. If someone has spoofed their email address, will they pay attention to some unknown email message, with a temporary password, and respond to it? I doubt it. Currently, valid users immediately think they can logon, which they can't. I have worded the welcome letter to try to explain the process in detail, but it is still confusing. If they can figure their way through this process, they come to my site and enter the temporary password. Most can not figure out that they need to reset it, although the message clearly states this.
The user status module, activate function, allows me to send out a second email that reminds them that they need to reset this password.
Now, where it really gets confusing is if I have the Invite module installed, which I do. I have to create a welcome letter that allows me to explain both methods of activating an account, because the Invite allows users to set their password.
What I am proposing is pretty much already there:
User registers and enters user and profile info, including a desired password (with double input verify routine). Both user and profile records for this user are created, with a status code of zero (inactive). The only additional element here is the entry of their password, everything else currently happens.
Welcome letter goes out and they are told that they are inactive, pending admin approval.
If their email address is invalid, I get a 'kicked back' email message. If the email address is spoofed, once again, they may not let you know. But they will certainly contact you when, and if, they start getting emails. I remove them, in either case. I review their profile info and here is where I have to take responsibility for the abuse or misuse of my own site. If I have set things up smart enough, there is data in their profile that helps me to verify that they are who they say they are. I ok them, their status code gets set to 1, email status puts out the second email. All is right with the world!
I cannot take the 'me' responsibility out of this process, with either method. Temporary passwords only guarantee one thing - your user registration process is going to have some additional, confusing, steps to it. Most internet users will be very confused. I have had to send out multiple emails to my users, explaining the password confusion, getting new passwords from them that they will remember (because the edit routines are way too confusing for most of them to use), resetting their password, then letting them know it has been reset. If, by this point, they haven't gotten totally discouraged, they may actually participate. I don't know about you, but I want my people to participate. And I don't want all of this extra work! I'd rather set some verification info in the original profile that helps me to know that they are who they say they are. Then activate them and get on with all my other work.
My 2 cents. Take Care, Sharon
Comment #18
dwwThis was fixed when I moved user_status.module into core. See http://drupal.org/node/144859