👤 Ask Guest to enter a name when connecting

[BornToBeRoot]

If a guest joins a conversation with a public link, ask him to enter a name.

I know you can change it here:

But i think the most won't do this... so why don't ask him when he connects.

[nickvergessen]

@jenniferpiperek what do you think design-wise?
New screen like for the password, combine it with password, or just a modal afterwards?

[BornToBeRoot]

Having only "Guests" in the conversation can be really annoying.

If a non authenticated user joins a conversation via public link (password protected or not). There should be a dialog in the center of the screen, where the user is forced to enter a name.

• It should not be pre-filled with the name "guest", so the user has to enter something
• Continue button should be enabled when the user has entered at least 3 characters
• No option to cancel/close this dialog

Something simple like this:

Edit:
With this "solution", the authentication / password page does not have to be adjusted

[szaimen]

#855 (comment)
I like this solution 👍

But actually I would only force the user to enter a username if he wants to write something, because sometimes I don't want to write something in a public chat but only see what others have written there...

[jancborchardt]

A blocking, even soft-blockong modal in this case is a no-go. It introduces an unnecessary step, one we actually had at some point and removed again.

How about this:
If you join as a guest with no name set, the message input placeholder says:

Writing as "Guest". Set your name

"Set your name" being linkified (primary color) and when clicked, opens sidebar with the name change input.
The rest of the message field is of course normally clickable.

Solves the issue nicely, gives feedback, and doesn't block anything. We only need to make sure it works well on mobile too.

What do you think @ma12-co @nickvergessen?

[nickvergessen]

Let's not mess with the div[content-editable]. It's bugous enough already with the mention chips and autocomplete.

At least the lobby waiting screen (which is already blocking) can have a direct setting option. Maybe an adjusted placeholder is enough as a first step, maybe even an opened tooltip to draw more attention to the setting?

[nickvergessen]

Added to the lobby screen with #3133

So I'm closing this as per above

[jancborchardt]

If we do hide the right sidebar by default, and the lobby is not activated (which normally it is not), then this will still be an issue. So I’d still say we keep it open?

What I proposed above will not mess with the contenteditable, but can insert a separate element floating a z-index above the input (or whichever way works). In any case – we should keep tracking this issue as it’s not solved for most cases.

[marcoambrosini]

Since we will have actions in the AppContent, one of these actions could be 'change name'. And that indeed could bring up the mini modal! It's also very mobile friendly!

[jancborchardt]

Since we will have actions in the AppContent, one of these actions could be 'change name'. And that indeed could bring up the mini modal! It's also very mobile friendly!

You mean the 3-dot-menu? This is too hidden for changing your name, since as a guest you might not look in the menu before you start writing.

What’s wrong with the subtle but clear message in the message input field as proposed above at #855 (comment)

[marcoambrosini]

What’s wrong with the subtle but clear message in the message input field as proposed above at #855 (comment)

Nothing really, just a pain of a component to touch xD
cc @nickvergessen

[jancborchardt]

It would indeed be nice to show a proper modal here. Not only for putting in the guest name, but also for showing the conversation image and name as a quick "Welcome".

Who is interested in making a mockup here @nextcloud/designers? :)

[szaimen]

I can do that :)

[nickvergessen]

If possible also account for the lobby in case it's active, e.g. before a webinar.

PS that one already has the option it seems but we need to "enforce it":

[szaimen]

Hi, here is my mockup:

Public call	Lobby

WDYT? :)

[Antreesy]

Are we agreed, that a guest shall not continue using (reading, chating) in the joined conversation, until he'll submit a name?
I thought that was blocking before

[szaimen]

Are we agreed, that a guest shall not continue using (reading, chating) in the joined conversation, until he'll submit a name?

Yes, that was the idea. Didnt I make this clear with my mockup?

[Antreesy]

Yes, that was the idea.

No, that's clear from mockup, but not from the UX point of view, in my minds at least.

We're forcing users to input something, and that will cover maybe 90-95% of users.
But this basically prevents guests from being anonymous. Maybe, consider that opportunity, and keep it as tertiary button "Continue as Guest"?

[szaimen]

That is why there is a placeholder guest. They could simply type in guest?

[Antreesy]

placeholder !== input, it should be clear when you have an empty input or a pre-filled one. That lead us to the question, what's better from design perspective, pre-filled input with "Guest", or an additional button?

Also if guests will type that themselves, That would be untranslatable, and supported on the language they've typed it and you're currently using. We have a wide support across the Talk for the default (empty) Guest, typing by themselves will break it:

[szaimen]

I would actually like to not introduce an extra button for users that want to not change their name. Why should we make it easy for them to keep using guest when we instead want them to enter their name?

[Antreesy]

I think, that returns us to 3-years-old discussion: #855 (comment)

It's just my opinion, but still, it's better to see t('Guest'), than non-translatable Guest, or even something less readable like whitespace ( ) which leaves a name row empty, or emoji (👍), which breaks avatars.
If person doesn't want to share his name, he could find a lot of other ways to avoid doing that, way worse for other users, than placeholder name. Maybe an additional button is not the best choise here, I agree