For users who do not have an IRC nick configured in FAS, we need to direct them to set one up. We need a mock up for a tool that helps new users set up their freenode nick and register it. should save out to FAS afterwards.
I'm envisioning this as a potentially multi-page wizard in a modal dialog.
See issue #310
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.
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.
(Mockup has been updated, see https://pagure.io/fedora-hubs/issue/283#comment-72139 below)
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:
- 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.
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.
When you first hit the wizard, this is what it will look like.
(Note how the "Register" button is grayed out.)
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.
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:
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 limit is indicated in server join message or /version:
RFC 2812 lists out allowed characters for nicks: https://tools.ietf.org
Note "Register" button is now lit.
Register button would remain grey. The "check availability" button reappears when nick is edited / cleared.
User clicks on "Register" button to continue registration process once an available nick has been entered an "Register" button activates.
If user cancels at this point, no data is saved, and they'll have to fill this page of the wizard out again.
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?
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.
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:
(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 )
Metadata Update from @duffy:
- Issue unmarked as blocking: #317
- Issue unmarked as blocking: #318
- Issue unmarked as blocking: #321
- Issue unmarked as depending on: #291
- Issue marked as blocking: #317
- Issue marked as blocking: #318
- Issue marked as blocking: #321
- Issue marked as depending on: #291
to comment on this ticket.
Copyright © 2014-2017 Red Hat
3.13.2 — Documentation