-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New User Onboarding Flow UI #16501
New User Onboarding Flow UI #16501
Conversation
started the job as gitpod-build-bmh-onboarding-form.1 because the annotations in the pull request description changed |
/werft run with-clean-slate-deployment=true recreate-vm=true 👍 started the job as gitpod-build-bmh-onboarding-form.3 |
@@ -13,7 +13,7 @@ | |||
"strict": true, | |||
"forceConsistentCasingInFileNames": true, | |||
"noFallthroughCasesInSwitch": true, | |||
"noUnusedLocals": true, | |||
"noUnusedLocals": false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Disabling for compilation to improve dx a bit. Once we have our linter enabled for PRs it will catch any unused vars rather than it be a compilation error.
/werft run with-preview with-gce-vm 👍 started the job as gitpod-build-bmh-onboarding-form.10 |
/werft run with-preview with-gce-vm 👍 started the job as gitpod-build-bmh-onboarding-form.12 |
/werft run with-preview=true 👍 started the job as gitpod-build-bmh-onboarding-form.13 |
I tried with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for making this happen, @selfcontained! 🔮
💭 I'd leave comments with suggestions in individual lines, but for the sake of minimizing the distraction, noise, and scope creep in this PR, I've added only one review comment about a component reusability.
❓ The only question that's possibly worth asking is whether we could skip the first + last name here and go with the proposal of the preferred name you mentioned in our recent discussion. Cc @loujaybee @phimae
🛹 I've also posted a slightly improved version of the flow in a relevant discussion (internal), that includes quite a few changes, including additional steps, better disabled states, skip option, and more. However, I'd not hold this back for the first iteration. Adding below three of the pages affected here in case we could grab any design bits that are easy to address here like copy changes, font styles, etc. See also design thinking (internal) behind these changes.
Step 1 | Step 2 | Step 3 |
---|---|---|
Approving to unblock merging, holding in case you'd like to address any of the UX suggestions.
/hold
{signupGoalsOptions.map((o) => ( | ||
<div key={o.value} className="flex space-x-2 justify-start items-center"> | ||
<input | ||
type="checkbox" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: We do have a Checkbox
component that could be helpful here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to make one, this was the first checkbox I've added ui for, so wanted to build it out a little, and will extract it to a component in a followup. Checkboxes are always so different than other inputs, so I wasn't sure what our UX pattern might look like for them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DEAL—Opened #16511 yesterday that mentions a checkbox component which is possibly worth splitting into separate issues for each form element. 🏓
@mustard-mh, Related Internal conversation |
thanks for working on this @selfcontained !🙏🏼 i'm having a look at the tracking of this now👀 |
value: "replace_remote_containerized_dev", | ||
}, | ||
{ label: "More powerful dev resources", value: "powerful_dev_resources" }, | ||
{ label: "Just exploring CDEs", value: "exploring_cdes" }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe make it (CEDs
) possible to add a link here?
And also other labels if it can help user to understand
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mustard-mh I think, He meant Cloud Dev Environments (CDEs)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A link would be great - going to leave that for a followup as I'd need to adjust a few things with how these labels render so it supports it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mustard-mh I think, He meant Cloud Dev Environments (CDEs)
Yep, I know it, but for users may don't know this shorthand new word 😂 just want to give them more context
started the job as gitpod-build-bmh-onboarding-form.21 because the annotations in the pull request description changed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/unhold |
Description
This adds a new onboarding flow for new users (currently we consider new users anyone that hasn't provided a preferred IDE). For those users, we'll show the following three step flow when they sign in.
newSignupFlow
feature flag that is enabled in non-production.fullName
on the user. Collecting as 2 fields is an attempt to help signal we're asking for real names and not aliases/usernames.user.additionalDetails.profile.emailAddress
user.additionalDetails.profile
user.additionalDetails.profile.onboardedTimestamp
to help us identify which user's have completed this flow in the future. We plan to introduce this flow, or a variation of it to existing users, and this will help us distinguish those that have gone through it.Related Issue(s)
Fixes #
How to test
Repeat the flow
You can also initiate the onboarding flow manually by appending the query param
?onboarding=force
to a url. For example:https://bmh-onboarding-form.preview.gitpod-dev.com/workspaces?onboarding=force
... should kick you into the flow even if you've completed it. This was mainly added to aid in testing, but could be helpful in the future to send a user into the flow manually.
With Starting Workspace links:
You can also test this with a workspace context link and include the
?onboarding=force
query param:https://bmh-onboarding-form.preview.gitpod-dev.com/?onboarding=force#https://github.com/gitpod-io/gitpod
Release Notes
Documentation
Build Options:
Experimental feature to run the build with GitHub Actions (and not in Werft).
leeway-target=components:all
Run Leeway with
--dont-test
Publish Options
Installer Options
Add desired feature flags to the end of the line above, space separated
Preview Environment Options:
If enabled this will build
install/preview
If enabled this will create the environment on GCE infra
Valid options are
all
,workspace
,webapp
,ide
,jetbrains
,vscode
,ssh