Status: ready for review
Overview
We are proposing to remove the username field from registration form and autogenerate a human readable username in the backend. This experience will be behind a Django configuration (default to existing experience). The human readable auto generated username will be visible to learners/staff/instructors in the same way as it does in existing experience but we will reduce the footprint of autogenerated username in the UX.
Problem
We are solving for 2 problems with this proposal:
Choosing a unique, valid username is a friction point in the registration step while we already are asking for another unique ID (i.e. email). Hence, we are proposing to ask for only one unique identifier i.e. email ID and remove username from the registration form.
Our SSO flow, asks the user to authenticate with a 3rd party and then lands the user back to the registration form which is an unnecessary step in the process. We do this extra redirection in order for learners to confirm their username considering it cannot be changed later; reference an example of this problem in openedX community.
Once we remove username from registration form, we will be able to not only create a simple, quick registration form experience but also a 1-click SSO experience.
Key Use Cases
As a learner, I want to create my account with as little friction as possible in order to start my learning journey.
Supporting data
Competitor analysis suggests that big ed-tech platforms are not asking for username (see ‘Competitive Research’ section below).
We ran a survey and a lot of users have complained about this friction in account creation.
We have run an A/B and are seeing a significant increase in CTR with removing username from the form.
We have data from both pt 2 and 3 but that are confidential to 2U and we would prefer to not share the data as part of this public proposal.
Solution
Our solution will be to make the following changes behind a toggle configuration that will default to existing experience. If/when set to ‘True’ it will allow following new experience:
Remove username field from registration form.
Autogenerate username while creating an account in the following format, where length of alphanumeric characters in the end will be configurable.
<fullname_initials>_<registration_year><registration_month>_<alphanumeric_characters>.Inform users about their auto-generated username on the platform.
Decrease the overall exposure of the username in learner-facing places in the platform where it’s not desirable, while retaining the places where it’s critical for support and instruction purposes.
Other Approaches Considered
In the past, we have improved this experience by suggesting usernames on the registration form (this experience is also a current experience for us). The suggested usernames were auto-generated from the ‘Full name’ and users could either opt one of the three suggested usernames or write their own while filling out the registration form. Some users do not prefer their real name in the username and our suggestions were based on real name. Even with that approach, we were not able to get rid of the ‘redirect to the form’ problem in SSO use-case.
Competitive research
Our competitors are not asking for username in the registration form and are relying on only email ID as a unique identifier. Unfortunately the way our system is built ATM, we cannot completely get rid of username easily, however, as a first step we can at least remove its friction in the registration step.
Technical footprint & Long term ownership/maintainership
Upcoming changes for simplifying registration form will primarily be made in following areas of the codebase
user_authn django app in edx-platform
Both the aforementioned areas, "user_authn app" and "Authn MFE," are currently owned and maintained by the "2u_vanguards" team. We plan to continue providing long-term support for these components.
Additional areas where we would like to decrease the learner-facing visibility of the username are covered in Remove username technical footprint - Externally shareable. Some of these are optional for this initiative but we feel they would be improvements to the platform. The minimum user-facing changes needed for this initiative are the configurability changes in the registration form and the addition of the auto-generation behind a django setting toggle.