The form with which the Candidate sets his/her e-mail address at the start of the process, or the form with which the registered user requests to change his/her e-mail address, are both provided as one field.
This configuration can lead to e-mail addresses being registered that lead nowhere, because the person has made a typographic mistake when typing his/her e-mail address. If this happens, the e-mail link to the person never materialises (and the potential new member is lost, ptentially forever as s/he will blame the infrastructure, not him/herself), or the user loses his/her e-mail connection to the platform, which is essential for a range of interactions with him/her.
Desired situation
The standard means to prevent this from happening is to use a confirm e-mail address field, with the requirement that the e-mail addresses in both e-mail address and confirm e-mail address fields must match.
I hence propose that the forms requesting the user to provide an e-mail address be complemented by a confirm e-mail address field, i.e:
at the start of the registration process;
in the /modify_member view.
In both cases, this confirm e-mail address field should be pre-filled with the same value as the e-mail address field, namely:
at the start of the registration process, the confirm e-mail address field should by default be emplty;
in the /modify_member view, the confirm e-mail address field should by default contain the current e-mail address of the user.
Current situation
The form with which the Candidate sets his/her e-mail address at the start of the process, or the form with which the registered user requests to change his/her e-mail address, are both provided as one field.
This configuration can lead to e-mail addresses being registered that lead nowhere, because the person has made a typographic mistake when typing his/her e-mail address. If this happens, the e-mail link to the person never materialises (and the potential new member is lost, ptentially forever as s/he will blame the infrastructure, not him/herself), or the user loses his/her e-mail connection to the platform, which is essential for a range of interactions with him/her.
Desired situation
The standard means to prevent this from happening is to use a
confirm e-mail address
field, with the requirement that the e-mail addresses in bothe-mail address
andconfirm e-mail address
fields must match.I hence propose that the forms requesting the user to provide an e-mail address be complemented by a
confirm e-mail address
field, i.e:/modify_member
view.In both cases, this
confirm e-mail address
field should be pre-filled with the same value as thee-mail address
field, namely:confirm e-mail address
field should by default be emplty;/modify_member
view, theconfirm e-mail address
field should by default contain the current e-mail address of the user.