Feature Proposal: Make UserRegistration as lean as possible

Motivation

Spin off from MakeUserRegistrationCustomizable.

Claims made:

• Main.KennethLavrsen: "If we made our UserRegistration so that the "always there" fields above are always there (login name / password with the IF as currently in trunk) but any additional fields are the result of the additional fields present in the UserForm; then I believe 99% of our admins have no need to tailor the registration topic."
• Main.PaulHarvey: "I'd say it's correct, though there's the age-old problem of customising help text next to each field; but you're right, it would drastically reduce customisation pressures."
• Main.AndreJones: "I like this proposal [MakeUserRegistrationCustomizable, red.], and also agree that the default UserRegistration topic should only contain the most common fields (never understood Comments anyway)."
• Main.MichaelDaum: "Actually, user registration should be as simple as possible to keep the entry barrier low. The less - the better. Users can add any extra information later - if they want."
• Main.KennethLavrsen: "I agree we can remove any extra fields beyond the "always there". Except country. I would leave that in because the complex list of countries we have is not easy to later add."

Description and Documentation

Remove redundant fields

Remove all fields except:

• FirstName
• LastName
• WikiName
• Login Name - IF {Register}{AllowLoginName}
• E-mail address
• Password - IF context passwords_modifyable
• Verify password - IF context passwords_modifyable

Country can be kept (but hidden) for admins that want to offer this on their customized registration page (possible if MakeUserRegistrationCustomizable is done).

Remove redundant texts

Links

"If you already have an account, you can change and reset your password."

Who is visiting the registration page if you already have an account?

Data disclaimer

"Important: the information provided in this form will be stored in a database on the web server. This database is accessible to anyone who can access the server through the web (though passwords will be encrypted, and e-mail addresses will be obfuscated to help prevent spamming). Your country, or the country where the server is hosted, may have Data Protection laws governing the maintenance of such databases. If you are in doubt, you should contact xxx@yyy.com for details of the Data Protection Policy of this web server before registering."

For which sites and countries do we offer this text? Can we make this hidden so that admins can at least use it (translated) on their customized page?

Examples

Impact

WhatDoesItAffect:

Implementation

-- Contributors: ArthurClemens - 04 Mar 2010

Discussion

Interesting finding on form design: "Mad Libs" Style Form Increases Conversion 25-40%. Also called "narrative forms".

-- ArthurClemens - 04 Mar 2010

The hard-coded country list and formfield should go out of the registration form. It really doesn't belong there and is not reusable for different purposes. See this task with a couple of good ideas of creative reusage of country list in registration form.

-- MichaelDaum - 05 Mar 2010

How many re-use of the country list do you foresee?

For the customized registration form I could see needs for different kinds of lists:

• Names of departments
• Names of (international) companies
• Names of work/research groups

I would be nice if the "list to dropdown box" code is generic. For instance a list of names that gets translated to a dropdown.

Speaking of translation: if we distribute the country list, shouldn't it be translated as well? For a dropdown box we would need the (language independent) code and the translatable country name. See CountryNames for an example using a bullet list and MAKETEXT. Of course, with country codes only the code would be stored in the user form.

-- ArthurClemens - 06 Mar 2010

• I think a generic solution where you can put some INCLUDE with a field name and a topic name for the list is brilliant. And country would then be a matter of using a country list that we include in System web as a simple table.
• I do not think country list needs translation. If people need a country list, it is because it is an international site in a global context (all countries possible) and then English is the defacto standard. If a website is in French you would either not have a country list in the first place or you would have a costum list of France, Belgium, Luxemburg, Quebec etc etc. I think making the country list translated would be wasted effort and could additionally slow down the rendering of topics with this list.

-- KennethLavrsen - 07 Mar 2010

don't forget that if you make each field either a topic section, or a separate topic (or a combination of the 2 if we add a the INCLUDE topic list feature from the other upgrade proposal) then the registration form could be created using a single setting in the SitePreferences (to a list of sections / topics) and then use FOREACH to render it.

this is basically what I intend to use to allow a simple to configure list of skin widgets.

-- SvenDowideit - 07 Mar 2010

It would be very nice to store the country list in a separate topic to be used in a DataForm definition right away. It should be easy to reuse that list to generate the registration form options as well.

-- MichaelDaum - 07 Mar 2010

Country list in separate topic, no translation needed. Do we have consensus on this detail?

Sven, interesting way to do it. Sometimes making something very smart also makes it more geek if we are not careful.

Newbie admins need to be able to tailor the registration form adding their own custom fields. As discussed in MakeUserRegistrationCustomizable. And to make this possible it should not be need a small "escavation" to find out how the heck these Foswiki geeks have made things.

The current UserRegistration topic is very geeky also so I am not saying lets stay where we are. But I am saying that when someone copies the UserRegistration topic to Main web to tailor it, it should be obvious how to add and remove fields by looking at the existing topic and guess it from there.

Maybe we could even do the includes Sven suggests genericly. Something like %INCLUDE{"RegistrationSomethingToic" field="fieldname" size="number" section="text|textarea|countrylist" mandatory="on|off" that returns a table row that appends to the form. That would be intuitive and easy to understand. And it would take 3 lines of HTML comment text to explain how to add more fields.

-- KennethLavrsen - 09 Mar 2010

I think we have enough consensus on the spec above to let Arthur run with this one.

Accepted by 14-day rule after good debate.

-- KennethLavrsen - 24 Mar 2010

Done.

-- ArthurClemens - 05 Apr 2010