Conversations: public channels / private groups -> bad UX

[streaps]

Calling public MUCs "public channels" and private MUCs "private groups" doesn't make much sense, it just adds more confusion. I don't expect that you change your mind, but for the record: there are several users and developers who are not happy about that move.

Nearly all other platforms use the same word for the private and the public thing. Only telegram makes a real distinction between groups and channels, but in telegram channels are something different than the sprint "channel" idea.

Whatsapp: just groups (?)

Telegram: public and private groups (a public group is a supergroup)
Telegram has also public and private channels, which are broadcasts / feeds. Users cannot write, just read. Channels are something different in Telegram.

Matrix: public and private rooms

Slack: public and private channels
Slack has also "user groups", but that is something entirely different (a list of users that can be addressed by @groupname)

Mattermost: public and private channels

Rocket.chat: public channels and private groups/channels (they also called rooms).

Discord: channels

Hangout Chat: rooms (and conversations)

Zulip: public and private streams

[licaon-kter]

You did read what they've talked/decided in the last meeting, right?

https://wiki.xmpp.org/web/Sprints/2019_January_Brussels/Pad

[Echolon]

I still don't undestand whats making this complicated. Its easier term than MUC. And I don't see why someone should understand the difference?

[Ppjet6]

This decision of using different names/UI is also based off ideas in this article:
https://blogs.gnome.org/tbernard/2018/05/16/banquets-and-barbecues/

Of course there are trade-offs to it, and as far as I understand, what was discussed during the UX sprint in Brussels does not include splitting the application at all. I personally don't think that would solve the problem they were trying to solve in the article, just delay it. I do think though that in general making this distinction is important, because workflows in these types of MUCs are completely different.

It's a decision that a group of (mostly) client developers made together, because we're aiming at consistent UX between clients, (finally?). You're welcome to come and discuss it there[0] directly.

[0]: xmpp:[email protected]?join, or even xmpp:[email protected]?join.