Show rooms list before asking for nickname

[ltguillaume]

Intended behavior

Instead of presenting the user with a nondescript and somewhat confusing page asking for a nickname before showing a dashboard/rooms list with the available MUCs, I think it would be much more inviting to open the dashboard first, then showing a popup dialog (while the dashboard fades in the background) asking for a nickname as soon as a user clicks a "Join" button.

The goal here is to make xmpp-web more intuitive and inviting to (anonymous) users. It also makes the dashboard more of a landing page to let users explore the possibilities, without requiring any form of "commitment" from them.

Solution

Show nickname prompt as popup dialog after clicking "Join".

Alternatives

No response

Priority

Could-have

Users scope

guests

Affected features

login, rooms list

Pull request

no

[nioc]

While I agree on this general UX rule (provide contents before requesting user information), I think it is not relevant here.
I mean, it's a damn chat, just asking a nick should not be an obstacle 😄

It really depends on the usage, if you plan to just link your guest homepage somewhere without any explanation, it may be confusing, but I think that providing a /guest?join={jid} link is a more common practice and and in this case, it will be more difficult to display the nick prompt before loading room and handling error (nick already taken for example).

Once this is said, there would be another issue to be managed:
Landing page loading -> Anon connect (without nickname), display rooms, wait for user to choose a room -> then ask for nickname, but what we do after user come back to rooms list? Re ask or reuse the same nick?

Instead of presenting the user with a nondescript and somewhat confusing page asking for a nickname

👉 You are a bit harsh, this is a standard input with a Nickname placeholder and an User icon explaining what the user should enter.

As an improvement, we might add a help text:

I do not think adding an extra label should be relevant:

For benchmark, here a well known social network landing page, I think our nickname field is more explicit 😉:

[ltguillaume]

👉 You are a bit harsh, this is a standard input with a Nickname placeholder and an User icon explaining what the user should enter.

While you're talking about the clarity of the (let's call it) "widget" to fill in a nickname (which is perfectly clear imo), I was talking about the lack of context on the page: you're sending someone to another page, and all of a sudden they get asked for a nickname... but for what, really? It's unclear. There's no indication that afterwards they'll either enter this and that chat, or will be presented with a dashboard with several chats to choose from. And since the URL will probably also diverge from the page's URL they're coming from, it's disorienting and may even get suspicious.

The example of the "well known social network landing page" has the context of the company's logo, some text about what you're even doing on that page (and a known URL).

While I wasn't thinking of the "instant join" route when I proposed this, I guess the website that contains/the person that sends the link is more likely to give that context, while when linking to the dashboard/room list, it would be great for the end user to see the room descriptions before thinking of entering any of them.

[nioc]

I understand... but if the people you sent the guest link to don't trust you to just type a nickname... I can't help.

To put the context into perspective, this page was created after feature request #19, but my original purpose with this app is for registered users, which have a more classic UI login page and a customizable title:

May be modifying the guest landing page to a form like the registered one should be enough?
And if truly necessary, a customizable description.

This is the best I can do.

[nioc]

Something like this:

[ltguillaume]

Again, it's not about the widget itself. It's about the missing context, and the proposal above is not adding any context of value: it's still impossible to deduce from that what room you will be joining. That's why it would be so nice to first see the rooms list.

[nioc]

I understand, you want the user to browse rooms before anything else, but as I said, it is not that simple to implement it.

a customizable description

👉 I propose another way by letting admins write contextual information they want to give to visitors

[ltguillaume]

Ah, misread your post there, I was looking too much at the pretty pictures. My apologies.

I especially missed the word "customizable". That could already go a long way, really, perhaps allowing to add some HTML/the website's logo above it, so there's more coherence between the originating website and the xmpp-web instance.

[nioc]

Redesigning guest landing page is done!

Default (no custom):

With customizable logo and welcome text:

{
  //...
  logoUrl: 'https://avatars.githubusercontent.com/u/4777345?v=4',
  guestDescription: '<p>Welcome to our <i>webchat</i>!<br/>Please type a <a href="javascript:alert(1)">nickname</a>, then you can join a room!</p><p>This is a very long message to see how the UX is <b>responsive</b> on small screen devices.</p>',
}

[ltguillaume]

This looks great and is just the right amount of customizable. Thank you!

[Ppjet6]

This looks cool!

I was telling @ltguillaume that ConverseJS has a nickname input right when the user enters the chat, and countless times I've seen a user enter with their nickname set to the question they wanted to ask.. Terrible UX.

I think I like that we're keeping it before the rooms, but I'm no UI/UX designer. The added context will certainly make a difference I hope.

[nioc]

Thanks for feedback, now it's up to you to bring this context in local.js now 😃