Entering Wizard

• Assumption: Hubs user who has never enabled IRC widget before.
• Paths: Can enter this wizard from the chat widget teaser on a hub page with chat widget on it, or can enter this wizard from user settings page (still needs to be mocked up)

Enter from chat widget

Enter from user settings page

See issue #310

Wizard: Choosing a Nick

See https://pagure.io/fedora-hubs/issue/283#comment-71771

Wizard: Email / Password Entry

Now we need the user's email address and password to run the registration command with nickserv.

We offer the user a selection between the email address associated with their FAS account and a custom email address.

We also offer a password field, with two copies to make sure the user types it correctly.
I asked in #freenode about password char length. emerson said it is 289.
For password allowed chars, stick to ASCII.

Questions

• Should we just use the user's FAS email and not prompt for an email to simplify the process?
• Should we just pick a password for the user and not make it an option to simplify the process?
• If nickserv won't accept password (they have no guidelines for acceptable passwords), we need to handle the error condition.

Cancel Case

If the user cancels at this point, and re-enters at a later point, we should try their selected nick again to see if it's still available:
+ If it is not, we should start the wizard over from the first page.
+ If it is available, we should start from this page and recall any field information the user had entered (except for password)

Back Button Case

If the user hits the back button, we should preserve any field information the user had entered on this screen (execpt for password). In this case, the user may want to change the nick they are using and come back.

Wizard: Confirm Email Address

(Mockup has been updated, see https://pagure.io/fedora-hubs/issue/283#comment-72139 below)

Wizard: Finish

Just a simple notification to let them know they're all set.

After the wizard is completed, the user should be returned to the page from which they spawned the modal wizard (either a hub or their user profile.)

More regarding the lifetime of nick registration, after talking to freenode admins today:

• If you do not receive the email confirmation in a timely manner or ever, or if you type an incorrect email address and can never receive it: you can simply drop the nick and re-register with another email address.
• After 10 weeks of inactivity during which a user is not identified with their nick, it is considered expired. This means it may be subject to a db purge (which happen infrequently) or another user who wants the same nick requesting it be dropped so they can register it.
• Activity means "you logged in to the account, regardless of the nickname you used to do so." So this will be a very edge case with our ircb usage as long as we make sure we continue to authenticate the account with nickserv.
• if a nick does expire, and the user tries to log in again, their same credentials will work as long as someone else didn't grab the nick or the db wasn't purged.
• cases to handle:
• nick expired, still available: no issue, just log them in
• nick expired, db purge: re-register same nick
• nick expired, someone else grabbed it: need to re-register with new nick

Related Mockups:
- Widget behavior + dialog in case of nick registration lost: issue #318

After the wizard is completed, the user should be returned to the page from which they spawned the modal wizard (either a hub or their user profile.) The IRC widget will then be in a state where IRC as a hubs-wide feature is enabled but the individual hub's IRC channel needs to be turned on:

Here an updated design which Sayan and I discussed today. Sayan is concerned with the original design, that the nick check will take too long and users will click on all nicks and make the UI slow, and also that it has a cluttered appearance. In order to address that, but still allow for reducing user cognitive load by suggesting nicknames as well as making it clear with a single register button what nick would be registered, we came up with this design.

Wizard is launched as a modal window over the window it came from (either the user settings page for IRC/Chat, or a hub with the IRC widget.)

It is a simple nickname field with a check availability button that works similarly to the original design, but has a suggest nickname button to fill the form field based these heuristics. If all of these are taken, we can start adding incremental integers to the end of each with some reasonable limit.

1. FAS ID
2. Firstname
3. Lastname
4. First initial + last name
5. first name + last initial
6. first name + last name

NOTE: Max nick length is 16 characters. Allowed characters: https://tools.ietf.org/rfcmarkup?doc=2812#section-2.3.1

Clicking on 'Register' brings them to the next screen using the selected nick.

Initial Appearance of Nickname selection

When you first hit the wizard, this is what it will look like.

(Note how the "Register" button is grayed out.)

Nickname suggestiion

You simply press the suggest nickname button and it prefills the formfield for you. If field is not empty it clears it then fills it. User must click 'check availability' to check.

Checking nick availability

Once clicked, the "check availability" button will fade out and a spinner with a loading message will fade in to indicate that we are checking the nick's availability. In the backend I'm assuming you're trying to /nick to that nick to see if you get an error:

• If no error, fade nick background color to green, change message + icon to indicate that it's available and fade in a "Register" button. Success message: "Available!"
• If nickserv error, fade background color of nick to light gray, change icon to an X and error message to indicate not available. "Not available."

It might be faster in the backend to do a /info query on the nick. This will tell you explicitly if the nick is not registered; if it is it gives you the registration details.

Nick guidelines:

Nick limit is indicated in server join message or /version:
"NICKLEN=1"
RFC 2812 lists out allowed characters for nicks: https://tools.ietf.org
/rfcmarkup?doc=2812#section-2.3.1

Nick available:

Note "Register" button is now lit.

Nick unavailable:

Register button would remain grey. The "check availability" button reappears when nick is edited / cleared.

Final nick choice

User clicks on "Register" button to continue registration process once an available nick has been entered an "Register" button activates.

Cancel Case

If user cancels at this point, no data is saved, and they'll have to fill this page of the wizard out again.

Idea - Register Additional related nicks

Should we register the 'tail' (eg mizmo_ mizmo__ mizmo___) and 'away' (mizmo-away) (mizmo-afk) nicks for users silently and add to their nickserv account?

Wizard: Confirm Email Address

There's not too much we can do here, but this basically asks the user to check the email address they provided for an email from Freenode and to click the confirmation link in it.

Cancel Case

If user cancels at this point, save their chosen nickname and save their chosen email address. When they come back, check if their chosen nickname is available:

• If it is not, restart them on the first screen to choose a nick, and pre-fill in the chosen email address later on.
• If their chosen nick is available, restart them on the email/password seelction screen with the previously chosen email address pre-filled and re-register the nick with freenode. Take them to the email confirmation page next.

(When user clicks the "Didn't receive the email?", a form field appears for them to input an alternative email. See https://pagure.io/fedora-hubs/issue/317#comment-72137 )