Restart Conversation Button resets UserId by default

[darrenj]

Version

4.2.1

Describe the bug

Click Restart Conversation in the emulator restarts the conversation but also resets the UserId which should not be the usual behaviour as user state is lost, the typical use is to restart a conversation not a whole new uer

To Reproduce

Steps to reproduce the behavior:

1. Talk to a Bot that stores state (e.g. your name)
2. Click Restart Conversation
3. Talk to the same bot and your name will be prompted for again.

Expected behavior

• Restarts the conversation and maintains the UserId. User can click the drop-down to use a new UserId if they want

[bug]

[justinwilaby]

Checking with the team to understand the current implementation and why the user id is reset each time. I seem to recall this was explicitly decided on but I can't recall the reason why

[cwhitten]

I believe the designed behavior is that Restart Conversation defaults to a new User ID, and the user can select to generate a new User ID via the dropdown, so the inverse of your provided expected behavior.

cc @mewa1024

[darrenj]

Would be good to review the designed behaviour :-) I can help with examples/scenarios if helpful.

[mewa1024]

@darrenj Yes, examples and scenarios would be useful. Vishwac and I decided to restart with new user ID by default (#298). In user studies with the Basic Bot, users were surprised when they restarted the conversation and the bot remembered their name, but this might be an issue that only affects new users so if you provide other examples, that would be great.

[ryanisgrig]

I would expect the button to use my last selected option, as I see value in both approaches. Some users may need to test a component of their bot related to a new user state (onboarding, authentication, new channel). Others may be running scenarios where a user is already authenticated or a component that does not rely on the user state.

[darrenj]

Looping back with more information. State management for a Bot is key, the fact that it remembers your name, preferences, settings is key. In fact the second+ time you speak to a Bot it should introduce itself differently than the first time.

Therefore, the UserId (from.id on the Activity) is key to be maintained across multiple conversations and is how we with the Telemetry stack are able to understand various conversations a user has.

from.id will be persisent across many channels (e.g. FaceBook, Teams, etc). WebChat is different in that it's not a persistent channel and therefore unless explictly set will generate a new unique Id each time.

The current UX implementation all too easily causes a developer to "loose" their state in a given session causing them to start again, the default is "Restart with new UserId". The developer has to carefully click the dropdown error and choose the "Restart with same UserId" option.

My suggestion would be to enable a default to be set, click the drop down and perhaps a checkbox or similar on the behaviour you want thus making it easy to control/override. We could put it in settings but that's a bit of a pain to go and change on the fly.

Thoughts @mewa1024

[tonyanziano]

In that case, what if we just switched the default of the button to be "Restart with same userId", and the user had to click the dropdown to restart with a new user id?

[mewa1024]

@tonyanziano @darrenj @ryanlengel Ah. I get it: we can't safely assume devs wants to the new userid versus the same userID:

Options:
1 - two separate buttons ("Restart conversation with new userID" and "Restart conversation with same user ID") (1 click)

2 - one button that says "Restart conversation [down chevron]" that opens a menu with the items "With new userID" and "With same userID" (2 clicks each time)

3 - a split button with one option as a default and a way for the user to change the default (I think we can do this in a dropdown menu). (1 click if you use the default, 2 clicks when you want to switch). On hover, text will say either "Restart conversation with new user ID" or "Restart conversation with same user ID".

Let's not do 1. So I think question is whether devs switch back and forth that often. If it's more common that a dev uses one and not both, then I think we can go with 3.

[tonyanziano]

This should be fixed by #1422

[cwhitten]

Addressed in #1422