Banquets and Barbecues

tl;dr: We’re splitting up Fractal into two separate apps: One to replace IRC, the other to replace Telegram.

This is an in-depth post on the thinking behind the split of the Fractal app, which was decided at the hackfest in Strasbourg last week. For more information about the hackfest, have a look at my other blog post.

1-1 woes

One of the biggest problems with Fractal at the moment is that 1-1 messaging is pretty terrible. Since the rooms in the sidebar are sorted by most recent activity, high-traffic public rooms (such as GNOME IRC channels) tend to drown out rooms with less traffic, such as 1-1s and small groups. This is problematic because the signal-to-noise ratio in 1-1 chats and small groups tends to be much higher than in high-traffic public rooms. This leaves the user constantly searching for the rooms they care about, while the rooms they don’t care about are always at the top.

1-1 chats are quickly drowned out by high-traffic public rooms in the sidebar

One way to solve this problem is having a favorites group for “important” rooms. This is a feature Fractal has had for a while, and it does solve some of the problems with a room list sorted purely by recent activity. However, it only works well for rooms that are important over long periods of time, and needs to be managed manually. 1-1 chats are often brief, and there can be many of them in parallel. Putting them in favorites doesn’t make sense in many cases, as it would balloon the size of the favorites group, and require lots of manual work when starting or ending a conversation.

The “obvious” solution would be doing what Riot does: Having a separate group of 1-1 rooms in the sidebar, and thereby keeping the 1-1 conversations in one consistent place. However, this creates more problems than it solves. In practice, it results in multiple groups of arbitrary length competing for real estate in the sidebar. If you have a lot of 1-1s, this means that you’ll be able to see very few rooms (even when most of the 1-1s are old and not relevant at the moment). In Riot, this group is capped at 10 visible rooms by default, but that’s still not great if you only need 2 of them at the moment. The category can be collapsed, but then you can’t see which 1-1s have new messages, and it also means lots of busywork collapsing/expanding the group. Clearly this isn’t an ideal solution, which is why we were very hesitant to go down this path.

Riot’s separate 1-1 category doesn’t really solve the problem, because old 1-1s take up a ton of vertical real estate when it’s expanded

A way out?

As we were discussing this issue over the past few months, I started looking more closely at the way people use different messaging tools. One thing I found puzzling is that despite the fact that Matrix theoretically supports the use cases covered by popular apps like Whatsapp and Telegram, few people are actually using it to replace those apps. Instead, they use it to replace IRC and Slack.

Why? My theory is that most chat rooms fall in one of three categories:
Private Chats, which include 1-1s and small groups; Team Chats, which are larger, but still private and invite-only; and Public Rooms, which are basically like IRC.

Team Chats and Public Rooms share many characteristics: Both have relatively high amounts of traffic, and there’s a lot of noise. The main difference is that Team Chats are private and the members rarely change (e.g. a company’s internal Slack), while Public Rooms can be joined by anyone at any time, and there is no expectation of privacy (e.g. #gnome-hackers on IRC).

However, Private Chats have relatively little in common with the other two categories: They are low-traffic, and have little or no noise. This may sound like a small difference, but I think it’s the reason why 1-1s suck in Fractal/Riot/IRC, and why people aren’t using Matrix to replace Telegram.

The Banquet and the Barbecue

I’ve come to the conclusion that one app can’t cover all the use cases that the Matrix protocol supports, and still provide competitive UX. If you design an app to deal with lots of high-traffic rooms (e.g. Riot as it is today), it will suck for 1-1s, so people will use something else for those. Similarly, Telegram is primarily designed for 1-1s and small groups, which is why it’s a terrible experience if you have many high-traffic groups.

If we want Matrix to succeed as more than an IRC/Slack replacement we need multiple apps, each focusing on a distinct use case. For messaging, I think the most important distinction to make is between what I call the Banquet and the Barbecue.

Slack is one of the most widely used apps covering the Banquet use case

The Banquet is a big, loud place. There are tons of people, and you don’t know many of them. Lots of things are happening all the time, and it’s hard to keep track of everything. This is what Matrix is currently mostly used for. Slack, IRC, and Discord are also all in this category.

iMessage is a good example of an app focused on the Barbecue use case

The Barbecue is at the other end of the spectrum: It’s a calm, private environment where friends, family, co-workers, and other acquaintances hang out. Conversations are mostly between 2 or 3 people, slow, and often very personal. Telegram, Whatsapp, iMessage, Facebook Messenger, and a myriad of other chat apps are optimized for this use case.

Fracturing Fractal

Now, what does this mean for Fractal? After a long discussion on Thursday, we decided to split up Fractal into two separate apps with different interfaces, each containing a subset of the user’s Matrix rooms.

Exactly how rooms will be split between the two apps is not 100% clear yet. 1-1s are clearly Barbecue, public rooms are clearly Banquet, but private groups could go either way. For these cases we may need a way to explicitly move rooms between apps. The distinction should probably be part of the Matrix spec, so the intent for a room to be a Barbecue or Banquet room could be set when creating a room, and persist across devices.

The two apps will share practically all the internals, and even large parts of the interface. However, the split will allow us to do some things differently in each app to optimize the interfaces for the different use cases. Some of the changes we’re considering are a bubble-style message view in the Barbecue app, and more room categories (such as low-priority) in the Banquet app’s sidebar.

For more details on the split have a look at the blog posts by Daniel, Eisha, Julian, and Adrien.

Messages and Discussions

How exactly the apps will be branded (and what will happen to the Fractal name we all love) is still being decided, but there is some consensus to move to GNOME-style generic names. The Barbecue app will almost certainly be called “Messages”. For the Banquet app there’s less agreement, but my current favorite is “Discussions”.

Early-stage mockups showing what the two different apps could look like

The Fractal brand will not go away though: We’re thinking of keeping it around as the name of the community project that develops both GNOME Matrix apps, and/or using it for the backend powering both apps.

There are lots of details to be figured out in this transition, both from a design and an implementation perspective, but I’m very excited about this new direction. If you’d like to join the effort, come talk to us on Matrix.

Note: I have no illusions that this change will magically get everyone to leave Whatsapp/Telegram/iMessage and move to Matrix. In the short term, the goal is simply to make Matrix 1-1s a good experience. That said, if we ever want Matrix to make inroads with the general public, I think a move in this direction is an important precondition.

16 thoughts on “Banquets and Barbecues”

  1. This is an interesting direction, but one of my most common use cases is switching from a public, high traffic chat room or a team chat room to 1-1. This is either (a) to move a detailed conversation about a technical topic to a space with less noise; (b) to have a personal conversation; or (c) to get a quick response from someone who may not be in a shared chat room but is logged into the chat client.

    1. The additional friction of switching windows is definitely a concern, but I think if the two apps are integrated well (e.g. allowing you to start a 1-1 from a contact in the Banquet app) it shouldn’t be a huge problem. It’s a trade off, but I think the more focused interfaces in both apps should more than make up for it.

  2. I’ve read so many blog posts about this barbecue vs banquet idea.

    As a long time slack/discord user I really don’t understand what the problem is.

    Slack has a long list of rooms/users and it works OK admittedly it is not great.
    I think the better model to follow would be Discord. You have two views “banquet” being the default and “barbecue” being a click away.

    I really think it will be a mistake to make two apps for messaging. I constantly flick between group and direct messaging and it works fine in discord. Having two apps is just going to confuse people who are used to having both modes of communication in a single tool.

    1. I can second this.

      I believe that Discord is the gold standard for messaging apps in many ways. Studying it closely would be of great value to any team developing an alternative. If it were an auditable, open source project I wouldn’t look elsewhere.

  3. Nice! My problem with Riot is indeed, that it tries to replace Signal (and the evil twin WhatsApp) with some kind of IRC. Therefore it offers a complicated and bloated UI. What I need for communication in general is a “barbecue” and for coordination a “banquet”. I think your on the right path, either seperate applications or a really clever UI (maybe two vertical panes aside, one with rooms and one with people?).

    But please, don’t use a generic names. It’s really hard to remember the name of an application or even tell people to start something, if the name is just an generic one. The .desktop-files make live so easy:
    Name=GtkParasite
    GenericName=Inspector for Gtk-Toolkit

    R. I. P. GtkParasite :(

  4. I’d say the reason why Matrix is not used to replace WhatsApp and Telegram is because the mobile apps of WhatsApp and Telegram are really great compared to the mobile apps for Matrix.

    1. I agree that this is an important factor, but I think before we can build great Matrix apps, we need to solve the fundamental problem that the protocol was designed to do more than a single app can handle.

      It’s a lot harder to compete with Telegram when you need to also support IRC/Slack/Discord-style use cases.

      1. I live in around 10 technical focused Telegram Super Groups, have family and close friend groups, groups created for our work “sprints” and 1 on 1 conversations.
        Personally, I do not find the UI hard. I believe most people do not find WhatsApps UI hard either.

        I do agree however that for this to take off, most matrix implementing apps need to sort of agree on a user interface, kind of how like all email applications sort of behave in a similar way.

        1. 10 is nothing, in barbeque land (e.g. GNOME IRC), many people have dozens or even hundreds of rooms :)

          But even with 10 highly active groups, you’re going to have a hard time keeping track of slow-but-important groups or 1-1s, because the high-traffic ones drown out everything else.

  5. I generally agree with Derek: a single button to switch the sidebar from groups to individuals would be enough, and simpler, than using two separate apps.

    But if you decide to go with this, I definitely think the clearest division between apps would be individual vs all group chats, regardless of their openness or number of users. “Messages” Vs “Discussions” sounds exactly like that.

  6. I also think this is an interesting direction, but I feel it’s maybe not the best to split it up into two programs with a clear cut without some overlap.

    In some way Matrix has the oppertunity to merge both IRC-style chat and IM-style chat into one program. Before this was mostly tied down to protocols even if there was no real limitation in the procotols. For ex. I have 1:1 conversations on IRC, but if it become more private it’s usually moved over to a more private IM-program (before XMPP, nowadays Matrix). I do like to have a very private space with people that are close but the divide is note made on the basis of if it’s 1:1, smaller-group-chat etc or not. So both programs need to be able to handle 1:1 (People) and public rooms/private rooms. I also wonder how you would handle forwarding/sharing of messages when you have to switch between apps. I feel it’s not that often that you actually add people to some kind of “private” list. But it’s still important to have that divide.

    Maybe it could be a setting to etiher automatically move all 1:1 chat to Messages, or that you do it manually by tagging them with “Private”/”Friends”. If every 1:1 chat would show up in Messages, it would be messy for me and divert me from the task at hand. For ex just having a shorter conversation with someone from a public room for a short while. In both apps you could have “Favourites”. An both apps you should always be able to easily share messages between all your contacts/rooms.

  7. Instead of splitting the same app into 2 similar apps, why not just keep Fractal and do the separation in the app itself? You could for example have a tab-view. Number of unread messages are displayed in the tab that is not in focus. And if wanted the user can drag the tab out of the window to create 2 separate windows, similar to the old Gimp. I think that would be a better option than having two too similar apps with different names etc..

    1. No, because splitting them allows us to optimize the UI in both apps for the respective use case, which benefits both apps.

      Splitting them allows us to have power user features to manage huge message volumes in the Banquet app, while keeping the Barbecue one clean and simple.

Comments are closed.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.