I'm against this switch. Group chats are used more and more often in IM than 1-1 chats. Keeping them separate was intentional as well, to make them better visible. What we could do, is to add a "switch" allowing user to change the order if he wants to.

Yes, they are. Ta a point where they are sometimes used for 1-1 chats... so why make them "special" and stand out? In general they are "high traffic" so they would naturally pop to the top of the chat list (unfortunately IMHO… but that could be handled with 'mute option' from sibling ticket).

Due to the same fact as we have a separate "group" for "From unknown". Moreover, if you will go to the roster and open a 1-1 chat, then you will be moved to the particular chat. For MUC there is no list of joined group chats, so without making them visible, you could "forgot" that you are in some groups or do not know that you were kicked, etc.

It is a different thing, so it behaves in a different way. To be honest, I hoped to do a similar thing on iOS - extract group chats to the separate list (another tab at the bottom).

OK, but in the end isn't this more of "technical limitation" than actual "we don't want it working like that"? The original issue was from purely user point of view.

IMHO it should be doable to have merged list with single (+) button which could pop-up a menu with two options: new chat - which would open current roster basically, or new group chat - which could open current join window, but it could be 'smarter' and, after typing the name indicate in the list that we are in that room already (maybe a small tag saying: "JOINED"?) and possibly, after selecting the item, switch from "join" to "open chat". So that would somewhat superimpose result from server disco and local, current list of joined rooms (more so considering some rooms are not to be listed, for example 'int' so it's not possible to join them.

Keep in mind that those are just my 5cents.

Bump? Making it optional? Currently constantly scrolling up and down between 1-to-1 and groupchats because in both groups some items have new messages but they are not in the same view is quite annoying...

To be honest I am in favor of current implementation. Separate group chats from 1-1 chats. However, I have just had a talk with Bartosz and he suggested similar approach to Wojciech. Maybe Wojciech and Bartosz use the XMPP slightly differently? Maybe they have much longer list of open chats than Andrzej and me?

In such a case I think it would be good to have an option to try and experiment with both approaches so really see which works best.

Moreover, I expect, that, indeed, if the XMPP / Beagle / Siskin / Stork is really used for communication, there might be a long list of both group and 1-1 active chats. We should think of the best way to manage this list to make it usable and comfortable to the user.

Maybe chats on the list should reorder automatically moving to the top chats which have some unread messages? Old chats, inactive for a long time should kind of hide themselves or "archive"?

I have a possible solution and it would be:

• add an option to allow users to see only one dynamic group (their choice)
• add Favourite section so that user could mark "important" chats and pin them to top of the list

To be honest I am in favor of current implementation. Separate group chats from 1-1 chats.

Why?

However, I have just had a talk with Bartosz and he suggested similar approach to Wojciech. Maybe Wojciech and Bartosz use the XMPP slightly differently? Maybe they have much longer list of open chats than Andrzej and me?

I have about dozens of MUCs and 1-to-1 chats and on 15" MBP screen this causes often scroll the list. With merged lists I wouldn't have to scroll at all.

Moreover, I expect, that, indeed, if the XMPP / Beagle / Siskin / Stork is really used for communication, there might be a long list of both group and 1-1 active chats. We should think of the best way to manage this list to make it usable and comfortable to the user. Maybe chats on the list should reorder automatically moving to the top chats which have some unread messages? Old chats, inactive for a long time should kind of hide themselves or "archive"? @kobit Well, both Telegram and Whatsapp use that approach - there is no distinction between groupchat or individual chat and chat list is ordered according to the last-received timestamp -- take it with huge IMHO, but I find it very intuitive. I think this boils down to "long list of chats" (it doesn't have to be very long to be honest).

Another UX in those apps is to have "archive function", which combined with "mute" simply puts those chats "out of sight" (Andrzej questioned logic behind this -- in Chile and Spain with huge prevalence of WA flood of "family groups" or "work groups" or "whatever groups" it's sometimes desirable to be in that group - sometimes you may want to ask something or organise something but not necessarily see this group constantly...)

Andrzej said:

I'm against this switch. Group chats are used more and more often in IM than 1-1 chats. Keeping them separate was intentional as well, to make them better visible.

But I'm not really convinced by that argument - what is the benefit of "making them better visible"? Do we want to promote groupchat?

"It is a different thing, so it behaves in a different way. "

And how is that important to user? As a user you are mostly aware that you are/were in a group, you are more than capable distinguishing them by: (a) name (either contact name or some group name), (b) icon (either contact picture or group picture, and in case of those missing default icons are different for groupchat and individual chat)

To be honest I am in favor of current implementation. Separate group chats from 1-1 chats.

Why?

Because I am different? Seriously, it does not matter why. People are different or maybe are not that different but may have slightly different use-case, hence different perspective.

Separating 1-1 chats from group chats reduces chances I can put some sensitive or personal information into group chat instead of 1-1 chat by mistake. Maybe we should also/instead separate public chats from private chats?

That said. I am really not sure which way is better for me, yet alone for everybody else. I probably have like 10 chats opened now. However, if our team grows to 20 or more people, I may have 30 or more chats opened all the time. I will not know for sure what would be the best UI to handle that until I try a few options.

However, I have just had a talk with Bartosz and he suggested similar approach to Wojciech. Maybe Wojciech and Bartosz use the XMPP slightly differently? Maybe they have much longer list of open chats than Andrzej and me?

I have about dozens of MUCs and 1-to-1 chats and on 15" MBP screen this causes often scroll the list. With merged lists I wouldn't have to scroll at all.

Ok, so how would that work if you had 2 dozens chats opened? You would have to scroll the list anyway. Think of the best solution for that.

Moreover, I expect, that, indeed, if the XMPP / Beagle / Siskin / Stork is really used for communication, there might be a long list of both group and 1-1 active chats. We should think of the best way to manage this list to make it usable and comfortable to the user. Maybe chats on the list should reorder automatically moving to the top chats which have some unread messages? Old chats, inactive for a long time should kind of hide themselves or "archive"?

@kobit Well, both Telegram and Whatsapp use that approach - there is no distinction between groupchat or individual chat and chat list is ordered according to the last-received timestamp -- take it with huge IMHO, but I find it very intuitive.

As said before, I am not 100% what would be the best solution. Following experience of others instead of reinventing the wheel is a good approach, however, it does not mean we should stop there. I think we can do better than others.

Also, UI distinction based purely on the underlying protocol, that is a technical aspects is incorrect approach. I am considering, that maybe, in the future, all chats, even 1-1 should be done over MIX. Does it mean they all automatically fall under groupchats?

If we implement distinction it should be based on the end-user perspective, instead of on some technicalities. Hence, I would prefer distinction: private chats (all 1-1 and maybe private group chats) and non-private chats (public group chats). Or something like this.

I think this boils down to "long list of chats" (it doesn't have to be very long to be honest).

"Long" is relative term. For me it means longer than I have now or long enough so it does not fit into the list view.

Another UX in those apps is to have "archive function", which combined with "mute" simply puts those chats "out of sight" (Andrzej questioned logic behind this -- in Chile and Spain with huge prevalence of WA flood of "family groups" or "work groups" or "whatever groups" it's sometimes desirable to be in that group - sometimes you may want to ask something or organise something but not necessarily see this group constantly...)

Yes, I agree with this and mentioned about something like this above.

Andrzej said:

I'm against this switch. Group chats are used more and more often in IM than 1-1 chats. Keeping them separate was intentional as well, to make them better visible.

But I'm not really convinced by that argument - what is the benefit of "making them better visible"? Do we want to promote groupchat?

Turns out, everybody has own preferences and own reasons behind them. Maybe some of them are just difficulties to adjust to "new stuff"? I think it is best to implement all the different options and let people choose, and experiment. We might be surprised ourselves what works best for us, eventually.

"It is a different thing, so it behaves in a different way. "

And how is that important to user? As a user you are mostly aware that you are/were in a group, you are more than capable distinguishing them by: (a) name (either contact name or some group name), (b) icon (either contact picture or group picture, and in case of those missing default icons are different for groupchat and individual chat)

I am not convinced by the "different thing" either and I am not convinced by "different way". It is sure different for us. We know all the story with 1-1 chats, MUC, MIX, etc.... But, is it really different for not so technical people? Does it really needs to behave differently?

On the other hand, when I send text message on my phone, it is hard to tell if I am sending it to a group or a single person. I made a few mistakes sending a message to a group instead of that one single person. Based on this experience I would really prefer to have well visible distinction not to make such mistakes.

Why?

Because I am different? Seriously, it does not matter why. People are different or maybe are not that different but may have slightly different use-case, hence different perspective.

Actually I think it does. Maybe we should pause a bit and think why we do things the way we do (or why we prefer one way or another)? (A bit food-for-though: https://en.wikipedia.org/wiki/Five_whys)

Separating 1-1 chats from group chats reduces chances I can put some sensitive or personal information into group chat instead of 1-1 chat by mistake. Maybe we should also/instead separate public chats from private chats?

OK, but even if we separate groupchats from private chats there is still non-zero chance, that you will send something to unintended recipient - correct? Maybe instead of grouping we should focus on what we should do to mitigate those cases ("make chat views more distinct" for example? We could consider retracting messages, but that's unenforceable in case of XMPP…)

That said. I am really not sure which way is better for me, yet alone for everybody else. I probably have like 10 chats opened now. However, if our team grows to 20 or more people, I may have 30 or more chats opened all the time. I will not know for sure what would be the best UI to handle that until I try a few options.

Hence pondering how and why we use the applications the way we use. (Also, we should take into consideration our habits)

I have about dozens of MUCs and 1-to-1 chats and on 15" MBP screen this causes often scroll the list. With merged lists I wouldn't have to scroll at all.

Ok, so how would that work if you had 2 dozens chats opened? You would have to scroll the list anyway. Think of the best solution for that.

Having about two dozens of chat items (MUC+private) doesn't mean that 100% of them are active and used constantly. In general those active bubble up on top naturally.

As said before, I am not 100% what would be the best solution. Following experience of others instead of reinventing the wheel is a good approach, however, it does not mean we should stop there. I think we can do better than others.

+1

Also, UI distinction based purely on the underlying protocol, that is a technical aspects is incorrect approach. I am considering, that maybe, in the future, all chats, even 1-1 should be done over MIX. Does it mean they all automatically fall under groupchats?

If we implement distinction it should be based on the end-user perspective, instead of on some technicalities. Hence, I would prefer distinction: private chats (all 1-1 and maybe private group chats) and non-private chats (public group chats). Or something like this.

Let's take this a bit further - what would be "private"? How "private groupchat" differ from public groupchat? Should we determine it purely on technical aspect of Groupchat configuration? In my case the distinction would be "work" and "non-work" communication, but I'm not sure mixing those two in single application would be the best idea. Maybe we should add labels to accounts and group chats based on those criterion?

But I'm not really convinced by that argument - what is the benefit of "making them better visible"? Do we want to promote groupchat? Turns out, everybody has own preferences and own reasons behind them. Maybe some of them are just difficulties to adjust to "new stuff"?

Habits are the worst thing in the world, and it takes virtually ages to change them :-)

I think it is best to implement all the different options and let people choose, and experiment. We might be surprised ourselves what works best for us, eventually.

I think @andrzej.wojcik won't be to fond with "moooreee options" approach ;-)

But on a more serious note:

• do we have any telemetry in the application to know which options users select? (do we even want to have it, considering privacy!?
• Apple doesn't give too many options to users yet they UI most of the time just "feels right" (so something along the lines of "quality instead of quantity")

On the other hand, when I send text message on my phone, it is hard to tell if I am sending it to a group or a single person. I made a few mistakes sending a message to a group instead of that one single person. Based on this experience I would really prefer to have well visible distinction not to make such mistakes.

@kobit OK, let's consider this a bit more - how do you usually send messages? Do you use platform's "share" feature? Or rather drag'n'drop/copy-paste? How do you avoid sending thins to other chats within same group?

Ok, I have to confess I am strongly influenced by the Kangaroo project during this discussion and I am seeing some elements from the perspective of the Kangaroo end-user. BeagleIM is not a client for Kangaroo system but there are some similarities hence my bias.

Why?

Because I am different? Seriously, it does not matter why. People are different or maybe are not that different but may have slightly different use-case, hence different perspective.

Actually I think it does. Maybe we should pause a bit and think why we do things the way we do (or why we prefer one way or another)? (A bit food-for-though: https://en.wikipedia.org/wiki/Five_whys)

Ok, I am stopping at the first "why": because we want the system to be useful and comfortable for the end-user.... Feel free to explore deeper.

Separating 1-1 chats from group chats reduces chances I can put some sensitive or personal information into group chat instead of 1-1 chat by mistake. Maybe we should also/instead separate public chats from private chats?

OK, but even if we separate groupchats from private chats there is still non-zero chance, that you will send something to unintended recipient - correct? Maybe instead of grouping we should focus on what we should do to mitigate those cases ("make chat views more distinct" for example? We could consider retracting messages, but that's unenforceable in case of XMPP…)

Yes, I am open to ideas. And it does not have to be one thing. Chat separation is one way to improve, maybe different chat background or something like this would help too. Assuming this is a real serious problem we want to put effort to solve.

What I mean here is. We can find a few reasons why we want to keep group chat on separate list from 1-1 chat. Then we can think of each of those reasons and try to solve each of them in a different way just to keep all chats on a single list. So we kind of put everything upside down. Maybe we should indeed explore this path... I am still open to ideas.

I have about dozens of MUCs and 1-to-1 chats and on 15" MBP screen this causes often scroll the list. With merged lists I wouldn't have to scroll at all.

Ok, so how would that work if you had 2 dozens chats opened? You would have to scroll the list anyway. Think of the best solution for that.

Having about two dozens of chat items (MUC+private) doesn't mean that 100% of them are active and used constantly. In general those active bubble up on top naturally.

Yes, this is definitely something we should have in place. I mean automatically reordering chats on the list based on their activity. I am personally in favor of this feature. I bet there are users who will hate that, though.

If we implement distinction it should be based on the end-user perspective, instead of on some technicalities. Hence, I would prefer distinction: private chats (all 1-1 and maybe private group chats) and non-private chats (public group chats). Or something like this.

Let's take this a bit further - what would be "private"? How "private groupchat" differ from public groupchat? Should we determine it purely on technical aspect of Groupchat configuration?

Public is a chat which content can be visible to non-members and is open for everybody to join. Private is a chat which content is not visible to non-members and membership is restricted.

In my case the distinction would be "work" and "non-work" communication, but I'm not sure mixing those two in single application would be the best idea.

Ok, now, I would hate to have to run 2 applications, one for work and one for non-work communication, when I could have everything in one place.

Maybe we should add labels to accounts and group chats based on those criterion?

Labels, tags and grouping chats by them might be the gold solution actually. I can think of a few different ways to group my chats.

For example, for the Kangaroo project we can have "internal" chats where all members are from our company and "external" chats where some members are from outside our company: customers, vendors, etc...

I can have private chats and work chats. I can have family chats and non-family private chats....

So, yes, actually ability for arbitrary tagging and grouping by these tags might be the best approach.

But I'm not really convinced by that argument - what is the benefit of "making them better visible"? Do we want to promote groupchat?

Turns out, everybody has own preferences and own reasons behind them. Maybe some of them are just difficulties to adjust to "new stuff"?

Habits are the worst thing in the world, and it takes virtually ages to change them :-)

We can either fight with how the world works or we can take advantage of it. I prefer the second option.

I think it is best to implement all the different options and let people choose, and experiment. We might be surprised ourselves what works best for us, eventually.

I think @andrzej.wojcik won't be to fond with "moooreee options" approach ;-)

Ok, so, let's do one option instead which covers all the use-cases :-) What about mentioned above tagging/labeling and grouping by those?

But on a more serious note:

• do we have any telemetry in the application to know which options users select? (do we even want to have it, considering privacy!?

Would be nice to have but I respect privacy more. We can always wait for users feedback.

• Apple doesn't give too many options to users yet they UI most of the time just "feels right" (so something along the lines of "quality instead of quantity")

From what I know Apple puts a lot of time, testing, experiments and just effort to have it right. And this is my approach too. However, with our limited resources we have to do it differently. Add some more options, release it to the wild and observe what works best.

On the other hand, when I send text message on my phone, it is hard to tell if I am sending it to a group or a single person. I made a few mistakes sending a message to a group instead of that one single person. Based on this experience I would really prefer to have well visible distinction not to make such mistakes.

@kobit OK, let's consider this a bit more - how do you usually send messages? Do you use platform's "share" feature? Or rather drag'n'drop/copy-paste? How do you avoid sending thins to other chats within same group?

Every time I made the mistake I selected a chat from the list on the mobile client. (iPhone Messages) It shows a list of chats. Group chats look the same as 1-1 chats, showing person name. In case of group chat it shows 1 or more people names. But if the first name on the list is the same as a name of the 1-1 chat, it is easy to make a mistake.

Thank you for all the input.

I would say that keeping "groupchats" separated and "on top" is more useful for "work" as from what I've learned while I worked in a company, people tend to have company-related discussions in 1-1 chats while they should use groupchats for that as it is easier to add people to the discussion, etc. Placing "groupchats" above 1-1 chats works well in this case as people will more likely use groupchats while they are on top.

That is why went with this approach. I agree it may not suit everyone and we can have "one common list" as an option if we want that.

I know that we should reduce the height of a chat item on the list, so we could place more of them on a device screen (single line of the message should work in most cases).

As for "archiving" - in terms of 1-1 chats it is the same as closing. In my opinion, we do not want to "archive" automatically anything as then the user will not know where the chat is and will forget that he joined this chat.

I see valid points for having a single list, so making it optional and having "more flexible" UI could be a good idea.

@kobit I know that BeagleIM is not for the Kangaroo project, but I'm using our client in a similar way to how (I think) Kangaroo clients will behave, so I'm also biased.

Just an idea. Maybe we could keep "separation" if we would add support for "pin/hide" as it is possible in Jetbrains Spaces? Actually having something like that could be useful even in "single list" mode.

Yes, I am +1 for this.

And still kind of custom grouping for chats. But maybe we will first experiment with this within Kangaroo project.

Could we also still have (optional) flat list?

Btw. we already do have groups in roster (potentially with multi-group entries) - maybe we could leverage that? This could actually play quite nicely in organisations that use DynamicRosters for this exact reason (grouping by department)?

+1 as always, I am in favor of implementing "everything" as available options for us to test and experiment with.

maybe we could use something like that?

A8917455-42BA-45CB-B47E-A61ABD12A3FD.jpeg

Sorry, I’ve added comment while not being logged in

maybe we could use something like that? @andrzej.wojcik that could work, but I fear that it would result in a bit of "dynamic" UI (relatively constantly showing and hiding "unread" category)

@wojtek That is why I'm saying we could use that, but the UI would be more dynamic as a result of that.

From our conversation today:

[2020-03-30 16:26:54] https://telegram.org/blog/folders - a może by takie grupowanie? domyślnie byłoby bez, ale można by sobie dodawać foldery (grupy) i w ramach grupy można by sobie wybrać poejdyńcze kontakty i też meta-grupy (channels, groups, unread) -- moglibyśmy zrobić podobnei i byłaby też meta-grupa "unknown" więc jakby ktos miał potrzeba zgrupowania to mógłby sobie dodać wg potrzeby? [2020-03-30 16:27:41] <Andrzej #> że takie zakładki zmieniające scope? [2020-03-30 16:27:50] <Andrzej #> jest to jakaś koncepcja [2020-03-30 16:28:13] niekoniecznie zakładki - u nas mogły być grupy jak teraz, tylko zawartość byłaby dynamiczna [2020-03-30 16:30:10] <Andrzej #> ale all, personal, work to ciekawa opcja..

Yes, I like it. However, as I am working on our new project and designing UI, I am more and more inclined towards more generic approach, that is: tags. Instead of creating "folders" or "groups" or any other kind of grouping, I am thinking of implementing "tags". So user could apply tags to different objects: chats, contacts and other (yes there are more coming). Then, he could display elements by tags.

Those "groups" or "folders" are just that - the UX is just reversed - instead of adding tag to particular conversation (chat item focused) you add conversations to tag (tag focused). End result is more or less the same.

Yes, and... no.

If we talk about chats grouping only, then yes, it does not matter that much how you design the UI. However, if we are going to introduce tagging for stuff in our system (chats, contacts, and more...) then the UI should be consistent. Tagging should work in the same way for all these elements. Once user gets used to tagging, he could do this everywhere in the same way.

And, while I like the general idea on how they do it in telegram, I think the UI and workflow is kind of complicated. "adding" a tag to element/item should be simpler than that.

I'm not convinced that tagging is what we need. Let me explain that a little.

Right now we have "good" UI in chats list view for searching for and opening existing chat. They are sorted in and grouped in a more or less predicted way.

What we are missing is a good UI for seeing what chats are unread. As a solution I see 3 approaches:

1. Remove grouping This way most recent conversations would be kept on top. While that would work, I'm not convinced that this is the best solution.

2. Introduce "unread"/"awaiting response" group on the top, so that each conversation with an unread message would land there. This also could work, but it would make our UI more dynamic as conversations would move more (jump to and from this group)

3. Split chats list in 2 parts (this is just a concept, maybe into more sections). Then assign "equal" size for group chats on top and "direct messages" on the bottom. That way "groupchats" would not push out unread 1-1 chats as the same amount of each of them would be visible on the screen. I've attached a screenshot of how it could look like.

I'm convinced to the last option as it was something I was aiming for with initial design, but I've not anticipated what will happen when we would have more and more chats opened. Would suggest going with option 1 & 3 - that we could have single chats list for some people and grouped in channels and 1-1 chats for others while we would deal with the invisibility of unread chats.

Now, back to tagging.

I'm not convinced of tagging as I do not see how this would solve our issue with "invisible unread chats". Moreover, displaying tags would make the UI even worse (more data on the screen which is less useful for the user). Having an even more hierarchical structure of chats would not help us with invisible chats with unread messages.

I can see the benefits of tags when you are searching for something (i.e. our CTRL+F window could use them to search for conversation). We could even automatically tag conversations based on a group of the user in the roster.

As I've said, I'm not convinced to tags, and @kobit if you could draw an example UI and how it could look like it would be very good and it could convince me (or at least we could discuss this direction from the UX perspective).

As for having a unified way to tag stuff, that would be useful for searching or browsing and it should be unified. I'm just not convinced that tags should go into chats list.

chatslist-example-11585637558895.jpg

I'm not really convinced about (3) as it would still cause more movement/scrolling when some section would end up with more unread chats. After your message I started to lean more towards (1) & (2) - while the latter may work considering less animation (or if we make the animation somewhat subtle?)

I'm not convinced about global tagging (never got convinced to use it, neither in Finder not gmail - prefer good old folders but this is very IMHO)

As for animations - currently chat item with new message slides to current position, which in case of separation could lead to movement across whole least - maybe instead of sliding fade out item (especially at the bottom) and then fade-in in correct position?

I was pondering telegram UI for a bit (as it seems unobtrusive in this case) and there are a couple of observations:

• they sort chats according to last message received (so reading the messages doesn't affect item position)
• the animation is present, but it's very fast (this makes the UI feel snappier)

@wojtek We are also sorting by time of last received messages and if fact what you are describing is equal to my proposal no. 1.

And as I've said, I have no issue with introducing 2 looks, no. 1 for sure (as Wojtek prefers this one) and I'm trying to improve current UX with adding better visibility of unread messages. Both views have some pros and cons.

For sole thing about chats with unread messages, I was thinking of kind of a simple switch on top of the chat to show only chats with unread messages. Kind of like you have contact list with online users/all users. This way a user could quickly filter all chats with some new content in them.

1. Remove grouping - Sometimes, when I use the client grouping is useful, sometimes, a flat view is better. Again, my preferred solution would be a quick switch to toggle between grouped and flat list.
2. Unread on top, is kind of a variations of my proposition above. And I think it would be really useful. The only thing is that it should not be very dynamic. I mean, let's say you have a list of 5 chats with unread messages. You enter the first chat on the list. It should not change it's position until you leave the chat to switch to another. Otherwise it might be confusing and annoying. I think this is a very good approach, it just needs to be well thought through to be user friendly.
3. This is just a different way of grouping but the main difference here is that each group has a fixed size to display items. I understand that if there are more items on the list they would be scrolled within the group assigned area. It seems very interesting, however, I am not sure how would it "feel" in real use. Certainly would like to have it to try.

Back to tagging. One thing is implementation and another thing is presentation.

For chats/channels (maybe for everything else too), tagging would be presented/displayed as grouping. If I assign "favorite" tag to my chat, it would be displayed in "favorite" group on the chat list. So in essence, the GUI would not change much. And a user can use tags or not.

But tagging gives us a lot of interesting features. If I have a "favorite" tag on a contact, then opening a chat with that contact, would automatically assign the tag to my chat as well. Of course, every thing could have multiple tags. If we implement some integrations with other systems, let's say YT, then opening a chat related to a project could give the chat a tag with project name or even ticket number.

Why are we doing this at all? I expect, soon, people will be using this kind of communication more and more. As a result they will have more and more chats open at the same time. So, giving them a good UI to manage tens or maybe hundreds of chats is a key.

Space did a great thing allowing to attach chat to everything. This is a great idea. But the huge list of open chats in Space is unmanageable. So we have to think of a way to solve this part.

And yes, I am mainly thinking about Kangaroo project here...