Create MUC: default to local MUC service

[Nyco]

Problem

When a user wants to create a MUC:

• they are disturbed and confused by the "Groupchat address" input filed
• they don't know what to fill (even with example)
• they totally ignore theses concepts (MUC, MUC service, federation, local vs remote server)
• most users abandon or at best ask for help (or search)

Solution

We should, maybe:

• separate left and rights parts of the JID in two different fields
• pre-fill the domain part of the address on the local MUC service (need disco?)
• simply let the users create the MUC by just filling the room name (left of @ in JID)
• use friendly text such as "Name/ID" and "Description" (where "Name" is left part of JID and "Description" is "Groupchat description" a long free text)

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[laszlovl]

+1, I was actually discussing this in the Converse chatroom the other day. I also noticed that many people don't understand the fact that "groupchat address" requires a JID, and try to simply enter a room name there. This currently throws a cryptic "Remote server not found" error.

My initial proposal was to split up the user-part and domain-part (which can be prefilled) of the conference JID as you're suggesting, but there was a lot of opposition to that.

JC suggested to catch such "Remote server not found" errors and making it show a prompt "Did you mean XXX@YYY instead?", where XXX is your original input and YYY the local MUC service address. I'm not very enthusiastic about that option, as it creates a lot more friction for users that don't (and won't) care for the concept of remote MUC services. I also doubt whether this specific error condition can be caught in a way that's compatible with all XMPP servers, without inadvertently catching different error conditions as well.

I feel that the best compromise is to automatically append the local MUC service address if there is no "@" sign in the user's input for "groupchat address". Converse already does disco for this so it should be easy to add.

[Nyco]

After some user testing and interviews with 4 regular, real world users (non-techies, non-developers), I observed them use Converse, and then asked open-ended questions.

Observing in action, the reactions I had so far are:

• "Create group... oh I must create some kind of server? I am very bad at this..."
• "I entered an address, but there is spinner... huh, it's forever, I must have made a mistake"
• "Oh I think I get it, someone must crate the group for me, like you create an account?"
• "I don't understand the example in the input field"
• "No, no, no, and address again? I don't to know about that..."

And then, some want to persist by trying:

• <domain>.<tld> (Top Level Domain)
• <conference>.<tld>
• <domain>.<conference>.<tld>

Asking open ended questions after the hands-on test:

• The regular, real world users do not want to (be forced to) handle the protocol or addresses
• The regular, real world users do not want to know the protocol or addresses
• The regular, real world users want it easy and simple: one name to fill, period... I they can start inviting and directly chat

Solutions?

• Hide the domain part completely
• Add an "advanced" section or button
• Put the domain part at the bottom of the form

In any case, the domain part seems like it has to be pre-filled.
Set it by default to the local MUC service: if the user has a JID <user>@<domain>.<tld> then pre-fill <conference>.<domain>.<tld>). And let "power-users" modify it.

Both proposed solutions, so that the user does not have to care, and so that is not another complex IT concept to learn about.

Maybe not?

• Adding another step that catches error and tell the users what to do... well, adds another step. Indeed that is unnecessary friction: users agree with this.

[deleolajide]

In order to deliver a temporary solution that works for my users, I have added

 <input value="name@' + __e(o.muc_domain) + '" type="text".......................

[Nyco]

We have approached that issue differently.
We'll propose something new in a few days.
Meanwhile I keep this one open.

[Nyco]

#1593

[poVoq]

Maybe the "server" field could be a drop-down list with a few options to choose from (Admin defined)? Maybe even with human readable aliases instead of domain names?

I am mainly thinking this would simplify joining gateway transports like Biboumi, but I guess in larger organisations it might make sense to have certain MUCs live on different servers (for example an intranet server that is not available everywhere).

[curiousgeek123]

has this been fixed? I want the same feature.

[HughEks]

@Nyco If this is still relevant I'm a UX/UI designer who wants to contribute (not a coder unfortunately).

[jcbrand]

Hi @HughEks, we'd love for you to help out. How are you best able to contribute?

[HughEks]

@jcbrand Awesome! I'm completely new to Github and the OS community so I'm not sure what my options are here. Basically I'd like to do some UI work, preferably on large features, but small ones will do as well.

[poVoq]

More themes is one of the thing I would really like to see. @muppeth is working on a nice "RedPill" theme and there was this hack for a dark theme: https://gitlab.com/maxigaz/converse-dark

Maybe you could prototype on that?

Also, the fullscreen mode currently doesn't work very well on mobile, which is why there is a special mobile mode. But I guess the medium term goal is to have a unified fullscreen mode. This is probably also something that needs some design adjustments.

[jcbrand]

Yeah, if you can write CSS/Sass and improve the theming story, that would be awesome.

Designs and mockups will also help, but if we still need someone else to implement them, then it might take a while until they're implemented.

[muppeth]

@jcbrand It would be nice (though I guess this is getting offtop) to make it possible for user to choose theme they want to use.
I'll work on my theme to make it upstreamble (currently just hacked on top of the default theme) and push it asap (@poVoq thanks for motivation :P).
@HughEks Great to hear! Mockups would already help a lot to give some ideas. I haven't touch converse in a while, but now that more and more inexperienced users are pushed to communicate indoor, getting them to use converseJS is a bgood entry point for alternative chat systems (wherese they would need to install a client first which for a lot of people is already confusing).

[jcbrand]

@jcbrand It would be nice (though I guess this is getting offtop) to make it possible for user to choose theme they want to use.

Yes, this is an eventual goal. I've done some work recently to be able to save user-specific settings, which is a prerequisite for this.

I've created a ticket for this: #1981

[HughEks]

@muppeth @poVoq finalizing the dark theme sounds good! I can't write CSS unfortunately, but would love to suggest some mockups. LMK if there's anything I need to know before starting...

[HughEks]

I'm exploring these directions, WDYT?

[jcbrand]

@HughEks A few things have changed in the latest unreleased version of Converse.js

The "Features" section is gone for example, and the buttons at the top right are collapsed into a burger menu.

I'll try to get the unreleased version available somewhere for you to try out.

[HughEks]

@jcbrand Thanks! A screenshot will do fine.

[jcbrand]

@HughEks You can try out the latest unreleased version here:

https://conversejs.org/trunk/fullscreen.html