Create/join channel (groupchat)

[Nyco]

Followup of: Major pain points of Converse after a small user test series #1580

The major pain point was: "create and join a channel".

Reminder (copy-paste of the above mentioned ticket):

• (9) Channel join/create: why an ID? why a nickname? why query what? why configure afterwards? why not smart defaults?
• (9) XMPP/JID/address: I don't know what ID to type in, I don't want to type ID, I try but fail (0% tests passed)

We drew new screens with a pencil on a white paper:

• create a channel: 4 alternatives (A, B, C, and D
• join an existing channel: 3 alternatives (E, F and G)

We took influences from:

• Converse: we took as much as possible, changed as little as possible
• Slack, Discord: this is the type of messengers we are aiming at
• Telegram, WhatsApp, Messenger: this is what we want to avoid (old generation, interpersonal, mobile)

Create:

A

B

C

D The red annotations were made after the user test.

Join:

E

F

G

We tested those with 6 users (almost the same as the previous user test).

Users have chosen one "join channel" screen and one "join channel" screen:

We took qualitative feedback, that we classified.

Based on that choice and the feedback, we very rapidly drafted and handwritten set of screens.

Create Channel:

Create Channel (advanced options):

Join Channel:

We will iterate on that and propose an UI and specifications.

--- Want to back this issue? **[Post a bounty on it!](https://app.bountysource.com/issues/74701323-create-join-channel-groupchat?utm_campaign=plugin&utm_content=tracker%2F194169&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://app.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F194169&utm_medium=issues&utm_source=github).

[jcbrand]

Can you please fix the orientation of the images? it's not easy to see what's going on in your notes...

[Nyco]

@jcbrand

Can you please fix the orientation of the images? it's not easy to see what's going on in your notes...

Absolutely not, I think about your health: that was completely intentional, in order to stretch your neck ;-) Nah, just joking, ok, I'm on it.

[Nyco]

Here we go, all images rotated, sorry for the mess and the delay.

[jcbrand]

Thanks

[Nyco]

Here is a possible UI:

Create Channel:

Note: members is a field working in "find as you type" mode, type "a", it suggest "albert" and "alice but not "bob", etc.

Create Channel, advanced:

Note: each radio need text explanations for the normal/regular user (non-technical), maybe the wording needs review (as we don't have to map perfectly the protocol with the UI/UX)

Join Channel:

Note: we propose a list of local MUC, the search field filters, for example here we have "Help", "Jobs", and "Tools", if I type "o" then only "Jobs" and "Tools" and shown, and "Help" is filtered out.

What do you think of this?

[jcbrand]

You're missing a nickname input for all these mockups :) I like the idea of inviting members and setting the avatar immediately upon room creation. I also like having advanced options, but collapsed by default. Some of the wording definitely needs improvement, but no big deal.

What does location local/remote mean?

[Nyco]

You're missing a nickname input for all these mockups :)

Ooooh, I'm like you, I miss those nicknames, as my habit is rock steady, I resist change. ;-)

Actually, while doing these observations and interviews first and then user tests with hand-drawn UX, people reacted to nicknames, saying there is no need for a nickname, as adding a nickname is confusing and disturbing, feeling some more disorder and cognitive overload, one more field to type in. Clearly, they just plainly want the feature removed, so the overall user experience is way simpler.

To reinforce this, a simple market exploration shows nicknames per MUCs are used in no leading IM (Interpersonal: WhatsApp, Telegram, Facebook Messenger / Team Chat: Slack). They all use per-account nicknames (, or "display names", meaning a unique nickname is used in all groupchats). Doing differently is unexpected.

As we have tested those screen, and users have validated them, I'd say let's KISS (Keep It Simple, Stupid). Per-account nicks or "display names" (which means same nick for all MUCs).

That said, we can definitely think of a way to satisfy the "power XMPP users" category, which represents a few hundred users (maybe thousands) in the world, that would allow them to user per-MUC nicknames like the protocol allows. For example, this can take the form of an advanced setting in the MUC, hidden by default, a user action being necessary to uncover that option.

Concretely, we have the JID, so we can default nicknames for all MUCs to the left part before the "@" sign, and we can offer a field in the user's profile to setup a different nickname.

Example:

• if no nickname is set up, "john.wick@company.com" will default to "john.wick" for all his MUCs
• the user "john.wick@company.com" can setup a account-wide nickname to "Baba Yaga" which will be used in all his MUCs

I like the idea of inviting members and setting the avatar immediately upon room creation.

People have clearly preferred this.

I also like having advanced options, but collapsed by default.

That's less clear, but it is a good practice.

Some of the wording definitely needs improvement, but no big deal.

Absolutely, we'll research and test this as well.

Yes, the result of discussing with actual real users, this process is of a great value: we are not blind anymore, we clearly see and understand people's uses.

What does location local/remote mean?

Oh, sorry, I should have explained:

• local: means on the user's local server, that is to say, we take the user's JID, we use the domain part, we discover the services on that domain, find the MUC service, create a MUC here
• remote: means it is NOT on the user's local server, but on another server, meaning the user has to enter a remote XMPP server JID (people don't like IDs, and don't know about JIDs), or more precisely the MUC service on that remote server, then we create the MUC over there

[jcbrand]

I'm ok with defaulting to using the per-account nick (Converse already does that) and then we hide the per-MUC nickname field under the advanced settings.

Concerning local and remote. This is very confusing and doesn't make logical sense either. There's nothing inherently local about the MUC domain of the XMPP server that hosts your account. It can be on the other side of the world.

Instead of having local and remote radio buttons (which also doesn't make sense, because power users won't type the full JID, then open the advanced settings just to click an additional radio button), we can rather just have an input field default host which has by default the MUC of the user's XMPP host. Users who aren't scared of JIDs can then also still type the entire JID in the input and be taken to the right MUC.

[Nyco]

OK, makes sense.