Add new user's new username to the Registration flow

[daniellekirkwood]

Your use case

Can we add a screen/copy somewhere in the flow that confirms the user's username so that they are able to log in once the account is created successfully?

Figma link

From
To

Have you considered any alternatives?

No response

Additional context

No response

[t3chguy]

@daniellekirkwood I think this would be better served by #19305

[daniellekirkwood]

Yes, both issues are great. This one seems like a small quick change we could make whereas I imagine #19305 is a larger lift?

[t3chguy]

probably not by a huge margin

[kittykat]

We could do both: keep a reminder going of the user's username and log in automatically when they click the link in the email

[daniellekirkwood]

Great point, @kittykat

Let me change this issue to address the problem, rather than provide a solution and that should help.

[daniellekirkwood]

Hey
@niquewoodhouse It might be good to include the user's MXID somewhere in the flow here so that they've seen it. On mobile we use a "celebratory screen" but the screenshot above might be enough for now? WDYT?

@gsouquet the other issue here: #19305 is very similar, what do you think the estimate for 19305 is?

Both: We should decide how/if we want to merge these issues, or if we sequence them. Let me know your thoughts!

[germain-gg]

We should aim to achieve both issues. However #19305 seems to require a bit more effort

Let's sequence them as this appears to be a low hanging fruit and spend a bit more time to see whether we can get the server to issue an access token whne registration is succesful. It might require us to create an MSC to change the response frm the registration and the email confirmation endpoints

[niquewoodhouse]

Hey @niquewoodhouse It might be good to include the user's MXID somewhere in the flow here so that they've seen it. On mobile we use a "celebratory screen" but the screenshot above might be enough for now? WDYT?

Just curious - why is seeing their MXID helpful at this time? Maybe it came up in mobile testing? Im assuming a bit but I'm guessing most people won't really read much here and the MXiD is not helpful to them in this early stage of their experience, especially as its not useful for logging in? Web defaults to user name as the login (which might not be right anyway) and not MXID.

Here are some ideas around the issue:

---

Web celebratory screen with MXiD

• Content mostly copied from mobile flow

---

Web confirmation screen with username

• Less fun, just says username

---

I can see from the comments above we might do #19305 later on but just to mention some ideas for that:

Auto-login route option 1

• The current home/welcome screen shows username, so could log in and go straight to that

ele-web-auto-login-01.mov

[daniellekirkwood]

#19305 would be wonderful to implement so let's get that scheduled.

For the meantime, both of your suggestions are great @niquewoodhouse. @gsouquet is there much of a time difference? I think we'd prefer the celebration one?

To answer your question Nique, you're 💯 right that users don't need to know their whole MXID at this stage because web defaults to username (where mobile doesn't) but we also found in Mobile that folks don't ever really see their MXID as a whole cause it's "hidden" under a click. So if they've signed up and want to share it, they may not know what it is... Happy to move the MXID to another screen or part of the flow but I think it's worth testing putting it in somewhere... WDYT?

[niquewoodhouse]

Sounds good, was just really curious, thanks for explaining

[germain-gg]

We already have some bits to have confetti particles in the product. We could try and re-arrange that to slot them on the confirmation screen.
I'd recommend we timebox this and see what we manage to generate there

[germain-gg]

After some further discussion, this is actually a regression and should not be a thing (view https://matrix.to/#/!bEWtlqtDwCLFIAKAcv:matrix.org/$rZMYuTXH86_3vkTh3Au-QG-UWC0CcELIInCg9I9ioFw?via=matrix.org&via=element.io&via=mozilla.org)

Closing in favour of #19305