Improve 1st user registration usability [#76785]

Comment	File	Size	Author
#2	firstuserflow_2.png	653.88 KB	kika
#1	firstuserflow_1.png	1.32 MB	kika
	firstuserflow_current.png	1.37 MB	kika

Comment #1

kika CreditAttribution: kika commented 2 August 2006 at 20:17

File	Size
firstuserflow_1.png	1.32 MB

1st proposal takes seemingly a simple route:

After installer is completed, instead redirecting user to site frontpage user is going directly to user registration (step 2)

There are two slight variations whenever user goes to profile edit after registration (step 3a) and then to frontpage (step 4) OR goes directly to site frontpage (step 3b)

Seemingly a simple solution has a big issue: is this step 2 redirection hardcoded? what if custom install profile wants to take user somewhere else? Or what if they do their own registration implementation? Alternative would be having that redirect only on default install profile, custom ones can land to frontpage (as default) or define their own specific land target.

There are other details too:
- "comment settings" on profile edit is collapsed by default
- "locale settings" is made into a collapsible fieldset and collapsed by default

Log in or register to post comments

Comment #2

kika CreditAttribution: kika commented 2 August 2006 at 20:18

File	Size
firstuserflow_2.png	653.88 KB

2nd proposal is taking a radical route: 1st user registration is taken out the main drupal site and pushed to ealier step, to installer. That effectively reduces number of steps required and gives administratior immensive power right after he lands to his site (no "trapdoor links")

But there are problems of course:
- how it works together with install profiles? Should the registration be the hardcoded step or only present in default profile (custom profiles can implement their own behaviour, including their own 1st user registration -- is it not a unneccessary code duplication?)
- how can user registration forms be reused in installer -- all the validation and stuff?

Log in or register to post comments

Comment #3

pwolanin CreditAttribution: pwolanin commented 2 August 2006 at 21:10

I do like idea #2- user#1 registration handeled by the installer.

Reusing at least the validation part of the form should be easy.

Log in or register to post comments

Comment #4

eaton CreditAttribution: eaton commented 3 August 2006 at 17:02

I'm not sure I'm in favor of the installer itself handling registration for user 1. The less we can keep in that portion of the system the better, because distros and hosted systems may want to handle it very diferently.

I've been working on a project to address this specifically, and it's in CVS at the moment.

http://cvs.drupal.org/viewcvs/drupal/contributions/modules/welcome/

Welcome.module is a smallish framework for multi-step wizards that lets us set up series of forms to execute in sequence, pausing if there are validation errors, etc. As per Dries comments in other threads, the goal is to have it:

Introduce the user to drupal with a welcome screen, as does the current 'no nodes' page
Present the user with a simple form for setting up UID 1
Let the user name the site, set the slogan, and turn clean URLs on if appropriate
Set up a contact form
Set up an 'about this site' page with a clean url
Add a couple sample nodes for the front page
Disable itself when things are finished

Right now, it handles steps 1-3. I just haven't had a chance to put the forms together for steps 4-6. If anyone thinks this would be useful, I'd really love to have a few more hands on board with the workflow, wording, UI, and so on... any thoughts?

Log in or register to post comments

Comment #5

rbrooks00 CreditAttribution: rbrooks00 commented 3 August 2006 at 17:25

The proposal which I like the best is flow 1 and specifically flow 1 using alternative A.

I especially like the new front page presented when a user hasn't created any content.

The one suggestion I'd have here is that on screen #2 we should just go ahead and eliminate all of the tabs there. If you only have a "create new account" tab then why have any tabs when that is already clear from other contextual clues? That just makes the page look a little better.

Log in or register to post comments

Comment #6

eaton CreditAttribution: eaton commented 3 August 2006 at 17:52

I too lean towards option 1, with no manual editing of the profile as part of the initial setup. That's similar to the flow that wizard.module will offer, though instead of returning to the front page, it currently proceeds directly from step to step.

To answer kika's question:

The redirection is not hard coded; each profile gets an opportunity to return a URL for the redirection. In addition, if a profile wants to skip the 'congratulations, you've installed Drupal!' screen entirely, it could just put a drupal_goto() into its own function.

Log in or register to post comments

Comment #7

moshe weitzman CreditAttribution: moshe weitzman commented 3 August 2006 at 18:10

the distinction about whether the installer handles uid=1 registration or whether that belongs to the custom install profile is just geek stuff. i think flow #2 is excellent, and we should achieve it using whatever tools we think are best. i'd like to see welcome.module implement that, and then a welcomeplus implement the larger profile that dries has outlined.

our welcome page is pretty dumb since it talks about creating the first user even when that user has already been created. we know that and could smarten the page accordingly. kika's slides highlight this issue.

Log in or register to post comments

Comment #8

kika CreditAttribution: kika commented 17 August 2006 at 11:15

It's considered an important core patch now, upping it

What are the problems with the suggested approach #2?
* code duplication?
* UI duplication, 2 different variations on registration experience, crippling the learning?
* bloating the install with additional step?
* hard-to-make-decision 'hardcode the 1st registration into installer / put it to default install profile'?