Closed Bug 699866 Opened 14 years ago Closed 13 years ago

[Tracker] Registration flow is a bit too long and complicated

Categories

(Participation Infrastructure :: Phonebook, defect, P1)

Tracking

(Not tracked)

VERIFIED FIXED
2012-09-12

People

(Reporter: aakashd, Unassigned)

References

Details

(Whiteboard: [UX][Re-Design])

Attachments

(20 obsolete files)

Attached image registration userflow & associated gaps (obsolete) —
I went through the log-in process today and found a couple of issues in the flow. The attached screenshot shows some of the major issues present and possible solutions to the problems. Issue #1: After confirmation, users need to click on a link to go to the log-in page Issue #2: After initial log-in, users see a splash screen. It's not entirely obvious on what to do with the app after registration.
Good call. BrowserID removes the need for email verification step. CCing @cbeasley as she had some feedback on vouching flow with is somewhat related to registration flow. @aakash from a product planning perspective, should this be a dependency of Bug#665373 or is this out of scope?
It can be, but I think it's a bit out of scope. The use of BrowserID fixes some of the obstacles present in the beginning of the flow, but the Mozillians app needs to better handle what happens after initial registration (i.e. confirmation and initial login).
Would love to see some consideration for semi-automatic registration upon JS detection of the use of a URL in the name field, AJAXing in an hCard etc. Would greatly accelerate registration for a small but heavily Mozilla community overlapping set of people.
Target Milestone: 1.3 → 1.2
tantek - can you point me to a site that does this? It sounds cool. I want to make sure I understand all the moving parts.
Assignee: nobody → cbeasley
Blocks: 692288
We're going with the proposal outlined here - https://gist.github.com/93148e13884b89c32f4b This is going to happen in chunks and not in 1.2, so I'll move this out of the release.
Target Milestone: 1.2 → 1.3
Assignee: cbeasley → bram
Attached image Registration UX: 1 Mozillians Home (obsolete) —
What’s notable in the proposed registration flow: * The front and the register page will explain what, why, and how new contributors should join Mozillians. What’s the benefit? Who are the Mozillians? What will joining involve, and what will happen? Can user search for other users right away? Who will contact the user? * A step for common areas of interest that new contributors tend to get started with. We can do this by identifying the top groups, and then putting those groups as selectors in the common areas of interest. If users don’t do this step, a “general” steward will still contact the user. But we want to encourage it, because if users have selected things they’re interested in, we can get stewards from specific teams to contact them. * Areas of interest are translated to terms that are familiar to users. For example, Firefox technically belongs to the Platform team, and websites to the WebDev team. But new contributors know that they just want to help with “Firefox” or “websites”. They won’t know “platform” or “webdev”. So when users check the box, the text box below will automatically be populated with the words that Mozillians have used in groups. * Finally, each group’s information is going to be displayed at the last page, with websites, code repositories, IRC channels, and steward’s profiles. It allows user to take initiatives via multiple channels: GitHub, IRC, website, email.
Attached image Registration UX: 2 Join (obsolete) —
What’s missing in this wireframe: Explanatory information on the joining process. We can perhaps explain it using 1-2-3 steps, then answer really basic joining questions that new contributors might have. For example: * What is BrowserID? * Which email should I use: my Bugzilla email? My spam mail? * Who are all these people I should contact, and how can I contact them? * What is IRC, and how is it used within Mozilla?
Attached image Registration UX: 3 Enter Groups (obsolete) —
Things to note in this wireframe: Most common groups (look for most used groups currently used in Mozillians) are presented as a check box, so new contributors are not presented with a blank canvas. The idea is to have a good set of defaults to get them started, and if that’s not sufficient, let them experiment with adding new groups via the text box (which will be less accurate – remember, they’re new).
Things to note in this wireframe: When user check a box, the corresponding group will populate the text box below. Note that the group reflects the system that we’re using on Mozillians, and may or may not be the same as the check box labels. For example: Firefox belongs in the Platform team.
Attached image Registration UX: 4 Finish Registration (obsolete) —
Things to note in this wireframe: Every time the new contributor logs in, he will see this contact information. After he has been vouched for, this page will be replaced with the community directory and search interface. This is debatable, of course. This wireframe might also be missing an interface to change groups that the user is interested in. I wrote “might” because this page may not appear for very long before the user is vouched by a community member. But an example scenario, nevertheless: the user might not be interested in helping with websites anymore, and instead he wants to do translation projects.
Attached image Registration UX: 1 Mozillians Home (obsolete) —
Attachment #596099 - Attachment is obsolete: true
Attached image Registration UX: 2 Join (obsolete) —
Attachment #596101 - Attachment is obsolete: true
Attached image Registration UX: 3 Enter Groups (obsolete) —
Attachment #596103 - Attachment is obsolete: true
Attachment #596106 - Attachment is obsolete: true
Attached image Registration UX: 4 Finish Registration (obsolete) —
Attachment #596111 - Attachment is obsolete: true
Attached image Registration UX: 2 Join (obsolete) —
Added FAQ below the email address field. The text is not finalized yet, but it summarizes all the things that I think we should address in the registration form.
Attachment #596582 - Attachment is obsolete: true
(In reply to Bram Pitoyo [:bram] from comment #18) > Registration flow details: > https://wiki.mozilla.org/Mozillians/Phonebook#Registration This link isn't working for me... is there a better link to use?
Attachment #596584 - Attachment is obsolete: true
un-assigning from bram and looking for someone to pick it up.
Assignee: bram → nobody
Whiteboard: [UX] → [UX][Re-Design]
Depends on: 706626
Attached image Registration UX: 1 Mozillians Home 01a (obsolete) —
Posting the Registration UX from 1-4 (inline with Bram's wireframes). Aakash, John and/or Matej - reposting the copy etherpad here, if we want to make any revisions to copy: https://mozillians.etherpad.mozilla.org/registration-flow-copy
Attached image Registration UX: 1 Mozillians Home 01b (obsolete) —
Attached image Registration UX: 1 Mozillians Home 01c (obsolete) —
Attached image Registration UX: 2 Join 01 (obsolete) —
Attached image Registration UX: 3 Groups 01 (obsolete) —
Attached image Registration UX: 4 Finish 01 (obsolete) —
I *love* these new mockups, especially the various homepage states. Nice work Lee!
I agree. It's like biting into a york peppermint patty.
Attached image Skills / areas of interest autocomplete (obsolete) —
The text box in attachment 611006 [details] under “enter your own skils” will partially match a tag name or description.
Lee: These look great. There's a few copy changes in terms of exclamation marks, but I think we're good to go here and can move on to the next part.
Blocks: 737438
Blocks: 703183
Component: mozillians.org → Phonebook
Product: Websites → Community Tools
QA Contact: mozillians-org → phonebook
Target Milestone: 1.3 → ---
Version: unspecified → other
Hey Lee, can you e-mail me the assets/images for the carousel?
This is far too large. Breaking this up into a tracker.
No longer blocks: 703183, 737438
Depends on: 703183, 737438
Summary: Registration flow is a bit too long and complicated → [Tracker] Registration flow is a bit too long and complicated
Depends on: 766680
Attachment #611006 - Attachment is obsolete: true
Attachment #597692 - Attachment is obsolete: true
Attachment #596600 - Attachment is obsolete: true
Attachment #611005 - Attachment is obsolete: true
Attachment #611426 - Attachment is obsolete: true
Attachment #572023 - Attachment is obsolete: true
Depends on: 766760
Attachment #596580 - Attachment is obsolete: true
Attachment #611001 - Attachment is obsolete: true
Attachment #611002 - Attachment is obsolete: true
Attachment #611003 - Attachment is obsolete: true
Depends on: 766761
Attachment #611007 - Attachment is obsolete: true
Attachment #596585 - Attachment is obsolete: true
Attachment #596583 - Attachment is obsolete: true
No longer depends on: 766760
Moving to fixed with the last dependency now taken care of on dev.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2012-09-05
Target Milestone: 2012-09-05 → 2012-09-12
Bumping to verified - this went live long ago. Nicely done all.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: