Stop forcibly directing users to NewDot when they engage with the NewApp OldApp switchter

[kevinksullivan]

Problem

As part of Direct public signups to NewDot, we will continuously force public domain users into NewDot, even if there are valid reasons for them to use OldDot due to the unique functionality that exists there.

While the design doc has a few ways to address this, including a snippet that we can run in a user's account, and a design that will not redirect a user using specific OldDot URLs, that can still lead users to a frustrating dead end if they don't chat with us for support or hit the right link to get into Expensify.

Solution

Let's leverage the design in NewApp <-> OldApp switcher to update a user's preference and stop directing them to NewDot.

When someone engages with this cross-link, we should:

1. Update the classicRedirect value in the tryNewDot NVP, with an additional value that we use to offset this hard redirect.
2. Allow just user to continue to Olddot
3. Continue to ask the user for feedback on why they did this (which is already being implemented in the switcher doc)

CC @danielrvidal

[melvin-bot]

@francoisl Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[francoisl]

Haven't looked into this yet as I'm focusing on getting the first critical issues merged and deployed. If someone can take this over in the meantime, that would be yuge.

[francoisl]

@AndrewGable is this Return to Expensify Classic new option already merged? Or is there a WIP branch for it or something else?

[AndrewGable]

No Return to Expensify Classic feature is still in design doc review: https://docs.google.com/document/d/1Mw_YtYql2L4mwyGT_QHQx7mFqDVUc6mOCNIAZh-oWo4/edit

[francoisl]

@kevinksullivan does this need to be a Daily then? Looks like we're blocked on that doc.

Also how about we just update this in the doc instead? All we'll need to do is update the NVP tryNewDot as such:

newValue = {
    classicRedirect: {
        dismissed: true, // add this
        timestamp: "xx" // keep everything else
    },
    "other stuff": { } // keep everything else
}

[melvin-bot]

@francoisl Eep! 4 days overdue now. Issues have feelings too...

[francoisl]

Still waiting on the new button to be implemented.

However @kevinksullivan, I was just thinking of one thing: if we update people's tryNewDot.classicRedirect NVP when they click that button, it would also stop them from being redirected to NewDot when they sign in on other platforms (web). Is that fine?

[melvin-bot]

@francoisl Whoops! This issue is 2 days overdue. Let's get this updated quick!

[kevinksullivan]

However @kevinksullivan, I was just thinking of one thing: if we update people's tryNewDot.classicRedirect NVP when they click that button, it would also stop them from being redirected to NewDot when they sign in on other platforms (web). Is that fine?

yeah, I think that makes sense @francoisl . Since this only affects those with the NVP present, I think that solution would handle the case we were originally concerned with.

[francoisl]

Ok cool. Going to demote this to weekly for now since we're still waiting for the button to be implemented.

[francoisl]

Looks like Hybrid App is almost done and we can get back to this soon.

A couple threads where this was discussed recently in wave9:

• https://expensify.slack.com/archives/C05NJ4SLBMF/p1701993363537199
• https://expensify.slack.com/archives/C05NJ4SLBMF/p1701986253496699

[francoisl]

Hey @kevinksullivan I'm getting back to this one, and I have two questions:

1. I'm noticing that with the way the the switcher was implemented, we currently don't auto-authenticate you in OldDot. Should we change that? I feel like it would be smoother

Screen.Recording.2023-12-22.at.10.20.42.AM.mov

2. Update the classicRedirect value in the tryNewDot NVP, with an additional value that we use to offset this hard redirect.

To rephrase this, do you mean that if users try to manually open expensify.com/ at some point in the future after clicking the switcher, we should no longer auto-redirect them to NewDot, is that right? (i.e. disabling the auto-redirection)

[francoisl]

@kevinksullivan small bump on the above please ^

[kevinksullivan]

I'm noticing that with the way the the switcher was implemented, we currently don't auto-authenticate you in OldDot. Should we change that? I feel like it would be smoother

oh yes, absolutely.

To rephrase this, do you mean that if users try to manually open expensify.com/ at some point in the future after clicking the switcher, we should no longer auto-redirect them to NewDot, is that right? (i.e. disabling the auto-redirection)

Right, we should not redirect them to NewDot in any scenario once they've engaged with the switcher.

[MitchExpensify]

we should not redirect them to NewDot in any scenario once they've engaged with the switcher.

Why @kevinksullivan ? Clicking "Go to Expensify Classic" doesn't seem to me like a reliable indication that some wants to always got to Expensify Classic. What problem does removing the classicRedirect NVP solve for these users clicking Go to Expensify Classic"?

[kevinksullivan]

@MitchExpensify just to be sure, you're saying we should force them back into NewDot every session? Then they have to switch back each time?

[trjExpensify]

Yeah, and further fill out the survey again and again.

[MitchExpensify]

@MitchExpensify just to be sure, you're saying we should force them back into NewDot every session? Then they have to switch back each time?

I don't think clicking "Go to Expensify Classic" tells us anything concrete about why they are checking out OldDot so I'm wondering what the reasoning is to remove the classicRedirect NVP.

[francoisl]

Backend changes are done - currently waiting for https://github.com/Expensify/Expensify/issues/358172 to be merged as it updates the "Go to Expensify Classic" flow.

[francoisl]

Still waiting on the above, looks like the main App PR is close to being merged.

[francoisl]

That logic was added as part of the Exit Survey stuff it appears, though I'm seeing a small issue with how it was done. Submitting a PR for review shortly.

[francoisl]

This was deployed to production last week but the automation didn't work :/