Sign-up flow alterations

[rrhyne]

Marketing is altering the sign-up flow to better support self-hosted installations alongside cloud sign-ups based on user requirements.

The ask from us will be:

• Change the sign-up button to "Get started"
• Change the route to the new https://about.sourcegraph.com/get-started link (with a UTM parameter to aid tracking)
• Change other locations in the product (tour, etc) that link to sign-up to read "Get started" and the proper route

The timeframe for this will be after marketing makes these updates. It will happen either in a few days, or after the 27th of January, depending on the content platform team's development timeline.

[muratsu]

@rrhyne to update the details

[rrhyne]

Updated!

[philipp-spiess]

It seems like instead of altering the sign up flow the plan is to fork it:

• https://sourcegraph.slack.com/archives/C02HL0RNTGV/p1642098053063700
• https://sourcegraph.slack.com/archives/C02HL0RNTGV/p1642112686080400

@rrhyne I think this task can be closed?

[rrhyne]

No, there are two sites at work here. Fabiana's comment is regarding about.sourcegraph.com. We will need to make the changes above to sourcegraph.com.

[philipp-spiess]

@rrhyne Here are all the in-product links to /sign-up that I could find with various search queries:

Code pointer	Screenshot
ExtensionRegistry.tsx
OnboardingTour.tsx
ExtensionAreaHeader.tsx
GlobalNavbar.tsx
SearchNotebooksListPage.tsx
ProductSubscriptionForm.tsx
StreamingSearchResults.tsx
ButtonDropdownCta.tsx
SearchContextCtaPrompt.tsx
SignInPage.tsx
CodeMonitoringSignUpLink.tsx

Expect maybe the link on the Sign In page, I'd suggest we replace all of them with the new deployment-agnostic getting started context. WDYT?

[rrhyne]

Thanks @philipp-spiess... I love the formatting above and thanks for the screenshots!!!!

Code pointer	Note
ExtensionRegistry.tsx	Change link text to: "Get started", route to https://about.sourcegraph.com/get-started
OnboardingTour.tsx	This is from the recent work with the getting started widget. The current button text is "Sign up for Cloud". It should be "Get started". This also requires removing the button below this one which has the text "Install Sourcegraph locally".
ExtensionAreaHeader.tsx	Same as ExtensionRegistry.tsx
GlobalNavbar.tsx	Same as ExtensionRegistry.tsx
SearchNotebooksListPage.tsx	Change link text to: "Get started creating notebooks", route to https://about.sourcegraph.com/get-started
ProductSubscriptionForm.tsx	No action, I'm not sure how an unauthed user could access this page, so we'll leave it.
StreamingSearchResults.tsx	Change banner text to: "Get started searching your public and private repositories", route to to https://about.sourcegraph.com/get-started. NOTE: David is currently working on this, so his PR and your's might conflict.
ButtonDropdownCta.tsx	Same as ExtensionRegistry.tsx
SearchContextCtaPrompt.tsx	Same as ExtensionRegistry.tsx
SignInPage.tsx	No action
CodeMonitoringSignUpLink.tsx	Change button text to: "Get started with code monitors", route to https://about.sourcegraph.com/get-started

[philipp-spiess]

Put up a draft PR (since we don't want to merge this until the new /get-started is ready here: https://github.com/sourcegraph/sourcegraph/pull/30098

I have some ideas on how to further improve the experience:

• Right now, we add a returnTo link to a lot of the sign up flows I noticed. This way, after signing up, a user is supposedly returned to where they left off. Looking at https://github.com/sourcegraph/about/pull/5083 I don't think we do forward that yet in case the sign up flow results in a cloud sign up.
• I’m a bit concerned about the case where a sign up flow starts from a non-sourcegraph.com domain and is linked to sourcegraph.com. This is definitely unhandy if you're testing things locally (where the domain to link back should be https://sourcegraph.test:3443/) but what if on-premise installations also show some of these sign up buttons and some customers set it up in a way that their users need to sign up on their on premise instance? Is this a valid concern? If so, should we gate the changes and only make them for our dot com deployment?
• Do you have any advice on which UTM parameters to add?

[rrhyne]

Should on-prem installations display sign-up buttons? I thought those users were invited by the admin? I could be wrong though!

How would the returnTo link work with the sign-up flow? See this PR to view the workflow a user must go through after signing up. https://github.com/sourcegraph/sourcegraph/pull/29996#issuecomment-1019892346

We use UTM parameters to track actions on our sites that use Google Analytics like docs.sourcegraph.com and about.sourcegraph.com. With all the links here, we can use Amplitude to create event funnels for flows like Extensions to Signup to see how effective these items are.

[philipp-spiess]

Should on-prem installations display sign-up buttons? I thought those users were invited by the admin? I could be wrong though!

I checked and you are right. On-prem instances show nothing if a user is not logged in except the sign in page. Since that still links to the previous sign up page I don't foresee any issues.

How would the returnTo link work with the sign-up flow? See this PR to view the workflow a user must go through after signing up. #29996 (comment)

I guess with the welcome page this is irrelevant, yeah. Maybe just an artifact from an ancient time 😛 Should I remove existing returnTo props then?

We use UTM parameters to track actions on our sites that use Google Analytics like docs.sourcegraph.com and about.sourcegraph.com. With all the links here, we can use Amplitude to create event funnels for flows like Extensions to Signup to see how effective these items are.

Okay so with our Amplitude setup we can already join events from sourcegraph.com and about.sourcegraph.com? Great!

[rrhyne]

Philipp

Right now, we add a returnTo link to a lot of the sign up flows I noticed. This way, after signing up, a user is supposedly returned to where they left off. Looking at add cloud section v1.1 about#5083 I don't think we do forward that yet in case the sign up flow results in a cloud sign up.

Rob

How would the returnTo link work with the sign-up flow? See this PR to view the workflow a user must go through after signing up. #29996 (comment)

Philipp I guess with the welcome page this is irrelevant, yeah. Maybe just an artifact from an ancient time 😛 Should I remove existing returnTo props then?

@quinnkeast could you have a look at the reconstructed thread above and provide some advice?

[quinnkeast]

Returning to a path makes a lot of sense when the user's signing up in response to a prompted related to a moment in time (e.g. signing up to comment on a thread—returning to that thread to comment continues that flow). I don't believe we really have any of those moments in place in the product right now, where a user will be interrupting their flow to sign up, rather than signing up as the start of a new flow. @rrhyne please correct me if I'm forgetting a moment that we should preserve.

I think in most cases, we'll want Cloud users to proceed to a team-specific post-signup flow or first user experience to learn how to use the product.

[rrhyne]

@quinnkeast, I just now remembered you had a customer interview where you observed returnTo not working correctly while reviewing something else... so I think I am mistaken, on-prem users may in fact be asked to signup when doing things like viewing a link to code.

This is going to take some flow mapping. I'll check with someone more knowledgeable than me on this @philipp-spiess.

[philipp-spiess]

on-prem users may in fact be asked to signup when doing things like viewing a link to code.

This flow should be untouched by our changes though, as on-prem instances show the /sign-in view if no user is signed in. This may contain a link to /sign-up but we're not changing links from the sign in page anyway.

[rrhyne]

Great!