The Future of Group Messaging(thejarren.com)
thejarren.com
The Future of Group Messaging
https://thejarren.com/group-messaging
93 comments
Yeah, I honestly enjoy the loosely linear way that Discord's chat works for informal conversation. You just.... chat, unless you're replying to something a bit further up, then you mark it as a reply. It feels completely informal without the rigidity you get from Teams/Google Chat/Slack's independent versions of threads.
I feel like something like this makes sense in theory, but when you apply it to a group you'll have people either exclusively use the content feature or exclusively use the messaging feature. People don't want to need to think to chat, they just want to talk like they normally would.
I feel like something like this makes sense in theory, but when you apply it to a group you'll have people either exclusively use the content feature or exclusively use the messaging feature. People don't want to need to think to chat, they just want to talk like they normally would.
I think this is the best solution for moderately sized and mostly-responsive groups, especially when the conversations aren't really important. This is common with groups of friends.
However for larger groups and cases where you get more async communication I find it falls apart. In this case I like Zulip's approach of forcing every conversation to be a thread more. But honestly my favourite is still email's tree of comments (or Reddit sorted oldest-to-newest). It makes it easy to follow a threads and mute threads or subthreads. Few other systems deal so gracefully with tangential conversations which I find to be very common. Of course email has it's flaws, but for async discussion between a large number of people I find the ability to see the reply-tree to be the most effective.
However for larger groups and cases where you get more async communication I find it falls apart. In this case I like Zulip's approach of forcing every conversation to be a thread more. But honestly my favourite is still email's tree of comments (or Reddit sorted oldest-to-newest). It makes it easy to follow a threads and mute threads or subthreads. Few other systems deal so gracefully with tangential conversations which I find to be very common. Of course email has it's flaws, but for async discussion between a large number of people I find the ability to see the reply-tree to be the most effective.
> You’d have no sense of time, no sense of delay, no sense of conversational flurry, etc.
Wonder if there's an opportunity for a new UI pattern here, that would make the sense of time explicit. I imagine it could be as simple as a visual separator between the messages, that scaled with the difference between messages. Perhaps with logarithm of the difference, to dampen large differences. Right now all we get are capped timestamps. But what if we could get something like:
Wonder if there's an opportunity for a new UI pattern here, that would make the sense of time explicit. I imagine it could be as simple as a visual separator between the messages, that scaled with the difference between messages. Perhaps with logarithm of the difference, to dampen large differences. Right now all we get are capped timestamps. But what if we could get something like:
20:01 Hey there?
_
Hi! How are you? 20:10
20:10 Fine, thanks, getting ready for
the party. You coming?
Sure, be there in 10. 20:11
20:12 See you!
_v_
03:14 Home.
___
Me too. This was fun! 03:50
VVV
14:40 What are you doing after work?
> And at this point, Slack’s method of creating a separate thread in response to any message is by far the most effective, but feels clunky within the interface, as if it were an afterthought.
I disagree hugely. At least for casual messaging, they're far too heavyweight for 99% of situations that are perfectly well suited to comment replies. Our brains are fine at picking out the context.
For casual chat, you don't want to overstructure things. Also with threads now you have to have some way of managing previous contexts (do you need to scroll up to find/reply to threads? Is there some sort of weird thread view?)
I disagree hugely. At least for casual messaging, they're far too heavyweight for 99% of situations that are perfectly well suited to comment replies. Our brains are fine at picking out the context.
For casual chat, you don't want to overstructure things. Also with threads now you have to have some way of managing previous contexts (do you need to scroll up to find/reply to threads? Is there some sort of weird thread view?)
Yeah, I think what Discord does here is a lot better - you can mark a message as a reply to a previous message, but it stays in the main conversation rather than forking off as a separate thread.
Agreed that Slack's "main" thread view sucks and I only use the sidebar view, it's really difficult/cumbersome to move between threads. I think some kind of tabbed interface could work.
And I'm all for threaded conversations, something evolved from Slack's model. Purely linear is so damn noisy and participants are forced to follow a lot of uninteresting shit that could've gone on in a thread instead. This happens a lot even with chats with small groups of friends.
And I'm all for threaded conversations, something evolved from Slack's model. Purely linear is so damn noisy and participants are forced to follow a lot of uninteresting shit that could've gone on in a thread instead. This happens a lot even with chats with small groups of friends.
Slack and its threading model is one of the most frustrating communication tools I have ever used.
Zulip is unimaginably better for long-running semi-structured conversations, both for casual lurkers and heavy participants.
Zulip is unimaginably better for long-running semi-structured conversations, both for casual lurkers and heavy participants.
Yeah I've only tested Zulip briefly but it seemed like just that, Slack threads evolved. At first I was put off by everything showing in the main view, until I realized I could filter everything.
I think you're spot on. I also think the real spot for innovation here is exactly what you're alluding to. Don't touch the real-time feed, but give an alternate "catch-up" view so someone can ask for a formatted review of the last half hour of conversation. Or maybe even a replay mode to see the chat as it happened with a speed modifier to play back at 1x, 1.25x, etc.
I'd suggest a logarithmic playback. With the right choice of base you could probably strike the right balance between matching the playback speed without having to wait a linear fraction of twenty minutes when there's a pause in the flow. (With a bit of animation work you might even be able to express how much time is going by.)
That’s definitely an interesting take, and I do agree, though in some ways I think this approach can deal with that problem.
Obviously the “work” asked of a user to create a post would be a new roadblock, but if they’re automatically created in most rich-content scenarios, no additional work would be required.
Even now, the reply feature arguably takes as much work as writing a comment on a post, though to some degree it lacks that immediacy.
On the flip side, visiting a comments section tends to feel more timeless than the conversation thread, so by automatically creating these posts within the feed, there could be more long-term value in each post, without drastically disrupting the immediacy of the chat.
I wonder if that hurdle is too large to jump, or simply a new feature for a user to take a few days to acclimate to?
Obviously the “work” asked of a user to create a post would be a new roadblock, but if they’re automatically created in most rich-content scenarios, no additional work would be required.
Even now, the reply feature arguably takes as much work as writing a comment on a post, though to some degree it lacks that immediacy.
On the flip side, visiting a comments section tends to feel more timeless than the conversation thread, so by automatically creating these posts within the feed, there could be more long-term value in each post, without drastically disrupting the immediacy of the chat.
I wonder if that hurdle is too large to jump, or simply a new feature for a user to take a few days to acclimate to?
The bigger problem with reading chat logs IMO is you either read them backwards which is very complex but leaves you infinite room to keep going, or you pick a point in the past and read normally but you won’t be able to continue easily once you reach the end.
Ultimately, how many people actually care about chat backlogs. It’s 99% useless conversations that you can just skip over and participate in the current topic.
Ultimately, how many people actually care about chat backlogs. It’s 99% useless conversations that you can just skip over and participate in the current topic.
> Ultimately, how many people actually care about chat backlogs.
<cynical voice> The same people who want to wear Google Glass in bars...
<cynical voice> The same people who want to wear Google Glass in bars...
> Reading chat logs is probably like attempting to read the transcript of your family holiday dinner. It would be nonsense. You’d have no sense of time, no sense of delay, no sense of conversational flurry, etc.
This reminds me of a private virtual event I put on a few years ago which was done entirely over real-time text. There were a few people who wanted to be there, but wound up having a time conflict, so I set up to make a recording of the event—including timestamps, and providing a way to play it back correctly timed (optionally modulated by a speed control). It seemed to get a good reception.
This reminds me of a private virtual event I put on a few years ago which was done entirely over real-time text. There were a few people who wanted to be there, but wound up having a time conflict, so I set up to make a recording of the event—including timestamps, and providing a way to play it back correctly timed (optionally modulated by a speed control). It seemed to get a good reception.
I think the reason chat applications like Discord or Slack, are usually a clusterfuck, is because the people using them are not used to have an organized conversation. They are used to talk about everything without thinking about it too much.
IRC has also the same model and people usually stay on topic, because that's what they are used to, it's on their culture. The same goes for other forms of communication, if it is old enough to survive, it'll have a culture around them and newcomers will have to adapt to the old ones if they want to be part of the community. Doesn't matter if we reinvent the wheel once again, if you can't discuss about something staying on topic the chat room is going to become a mess in a couple of minutes if there are more than 10 persons involved. You can have 50 different rooms for different topics but people go where there are other people talking (nobody wants to talk in an empty room), you need to moderate those rooms but at one point you can be there 24 hours a day if you had just created your chat group for fun.
IRC has also the same model and people usually stay on topic, because that's what they are used to, it's on their culture. The same goes for other forms of communication, if it is old enough to survive, it'll have a culture around them and newcomers will have to adapt to the old ones if they want to be part of the community. Doesn't matter if we reinvent the wheel once again, if you can't discuss about something staying on topic the chat room is going to become a mess in a couple of minutes if there are more than 10 persons involved. You can have 50 different rooms for different topics but people go where there are other people talking (nobody wants to talk in an empty room), you need to moderate those rooms but at one point you can be there 24 hours a day if you had just created your chat group for fun.
> I think the reason chat applications like Discord or Slack, are usually a clusterfuck, is because the people using them are not used to have an organized conversation.
But those same people deal just fine in a group of 20 friends at a bar, where they naturally break out into several distinct conversations with the people close by, and move to be closer to other people if they want to bet part of a different conversation. Discord/Slack/et al. force everybody to be "that guy" who shouts across half a dozen people to join in a conversation at the other end of the table.
There have been a few projects I've seen where people are trying to do video chat in virtual 3d spaces with sound localisation based on your avatars proximity to other users, which I think is an interesting approach, but I don't have any ideas about how to make that "localisation" thing work in a text chat context, apart from the not very useful "exploding number of slack channels" solution...
In a chunk of my friend groups - "ephemeral Signal chats with disappearing messages set to 1 hour or 1 day" gets used fairly successfully, where a side conversation can be taken out of the "main group chat" with the intention of it _not_ becoming an ongoing new group chat. It's still way more friction than turning round on a bar still and joining the conversation on the other side though...
But those same people deal just fine in a group of 20 friends at a bar, where they naturally break out into several distinct conversations with the people close by, and move to be closer to other people if they want to bet part of a different conversation. Discord/Slack/et al. force everybody to be "that guy" who shouts across half a dozen people to join in a conversation at the other end of the table.
There have been a few projects I've seen where people are trying to do video chat in virtual 3d spaces with sound localisation based on your avatars proximity to other users, which I think is an interesting approach, but I don't have any ideas about how to make that "localisation" thing work in a text chat context, apart from the not very useful "exploding number of slack channels" solution...
In a chunk of my friend groups - "ephemeral Signal chats with disappearing messages set to 1 hour or 1 day" gets used fairly successfully, where a side conversation can be taken out of the "main group chat" with the intention of it _not_ becoming an ongoing new group chat. It's still way more friction than turning round on a bar still and joining the conversation on the other side though...
Well-written article which explores an issue with which we all struggle.
Here's another possible but related solution. Have two views, and have a control on the page that will swap between chronological and thread views. In chronological view, have vertical lines behind the messages that connect a message back to the parent message - if it was a response. Don't indent messages - I still want to see my messages on the right and everyone elses on the left. In the threaded view a) reorders messages, b) moves these lines to the left and c) indents the messages. Extra points for animating the transition between views.
As for the site, I know that other's likely have different opinions, but here's mine. I had originally viewed the site with a browser with script disabled. It still worked and was a pleasant read. I did observe an empty panel under "The Solution". Later I looked at it on a different machine where the browser had script enabled and found myself annoyed with animations that added no information. But the missing "The Solution" panel was present. I don't know it I'm an outlier, but I find motion to be VERY distracting when I'm reading.
Another complaint - general but I'll highlight this article - is the ratio of words to markup. For this article, the ratio was about 5% - meaning that only 5% of the characters in the html document were displayed to me the user. That is a very heavy overhead of markup. Is that just par for the course in modern web publishing?
Here's another possible but related solution. Have two views, and have a control on the page that will swap between chronological and thread views. In chronological view, have vertical lines behind the messages that connect a message back to the parent message - if it was a response. Don't indent messages - I still want to see my messages on the right and everyone elses on the left. In the threaded view a) reorders messages, b) moves these lines to the left and c) indents the messages. Extra points for animating the transition between views.
As for the site, I know that other's likely have different opinions, but here's mine. I had originally viewed the site with a browser with script disabled. It still worked and was a pleasant read. I did observe an empty panel under "The Solution". Later I looked at it on a different machine where the browser had script enabled and found myself annoyed with animations that added no information. But the missing "The Solution" panel was present. I don't know it I'm an outlier, but I find motion to be VERY distracting when I'm reading.
Another complaint - general but I'll highlight this article - is the ratio of words to markup. For this article, the ratio was about 5% - meaning that only 5% of the characters in the html document were displayed to me the user. That is a very heavy overhead of markup. Is that just par for the course in modern web publishing?
Hi, this is very valuable information for me. This is actually my first time developing a website, so I sorta brute-forced the content onto the site.
I'm new to that side of things, and it's a deep learning experience for me. I think my CSS styling is a mess, and the text is all over the place.
I'm using Gatsby.js and Sanity CMS on Netlify, though none of my projects are currently within Sanity's CMS because I couldn't figure out how to do that yet. Big learning curve for me. I wrote a bit about it on my blog, but sorry for the messy experience!
I'm new to that side of things, and it's a deep learning experience for me. I think my CSS styling is a mess, and the text is all over the place.
I'm using Gatsby.js and Sanity CMS on Netlify, though none of my projects are currently within Sanity's CMS because I couldn't figure out how to do that yet. Big learning curve for me. I wrote a bit about it on my blog, but sorry for the messy experience!
Since you (the author) are here, I’m curious to know how you created all those graphics and what tools and resources you use for the static images and animated images. They look very nice to me.
Thanks a lot!
Sorry I didn't comment on this earlier. I have a heavy background of video editing and motion graphics, so I used a mix of Illustrator, Figma, and After Effects.
+1
It was visually a pleasant read.
It was visually a pleasant read.
Just want to point out that I'm not criticizing the final result - which looks great on both mobile an desktop.
Excellent ideas
>connect a message back to the parent message - if it was a response
Assuming you've got a long list of timestamped messages, how do you identify which messages are continuations of old threads and which ones are starting a new conversation?
>connect a message back to the parent message - if it was a response
Assuming you've got a long list of timestamped messages, how do you identify which messages are continuations of old threads and which ones are starting a new conversation?
There would only be a line if the message was a "reply" to an older message. Meaning that user long-pressed that older message, and selected "reply". I'd expect that less than a quarter of messages would be replies, and that typically one would only bother replying to recent messages - just a few back in the chronological list. A message just typed into the bottom field isn't a "reply" in my definition, and wouldn't have a connector line.
Zulip is another interesting point in the design space IMO. I think it’s worth a look for its take on the identified problem.
https://zulip.com/
https://zulip.com/
I hadn't heard of Zulip before today, but I think they have a very good approach to this problem. In some ways it's like tagging each message.
IMO *chan's are still the best way to handle this, especially when you can expand inline. You maintain the linear flow of conversation, and linearity maintains its status in the foreground, but you can optionally expand into other the conversation history through repeated expansion (and following various trees)
Organization like in the TFA just totally fucks up the flow of conversation, and totally ignores the fact that conversation is a graph, not a tree, and you naturally want to hop between conversation topics freely. You want to cross-post.
Not to mention that AFAICT just totally ignores tangents-within-tangents, a perfectly normal model of communication.
The fundamental problem though TFA is solving really is the treatment of persons-involved as defining a conversation, rather than the topic of conversation itself; The article has really just recreated BBS thread topics, with permissions scoped to a group of users.
Organization like in the TFA just totally fucks up the flow of conversation, and totally ignores the fact that conversation is a graph, not a tree, and you naturally want to hop between conversation topics freely. You want to cross-post.
Not to mention that AFAICT just totally ignores tangents-within-tangents, a perfectly normal model of communication.
The fundamental problem though TFA is solving really is the treatment of persons-involved as defining a conversation, rather than the topic of conversation itself; The article has really just recreated BBS thread topics, with permissions scoped to a group of users.
> The article has really just recreated BBS thread topics
Well in both cases you are dealing with a self referential set of fractal UI/UX objects.
Feed <> Post <> Flat Comment thread <> Sub-Comment thread_1 <> Sub-Comment thread_2 <> _x
Multiple conversation threads inside a BBS post means you 'view' the post as a feed, 1st Order comments as Posts, and 2nd oder...
Branches become trees and leaves become branches.
Building a single 'view' to handle shifting perspectives is not easy and OP seems to have at least thought this through with a proposal to have 2 different modes.
I'm looking forward to part_2 and (and maybe comparing it to my own conclusions ;}
Well in both cases you are dealing with a self referential set of fractal UI/UX objects.
Feed <> Post <> Flat Comment thread <> Sub-Comment thread_1 <> Sub-Comment thread_2 <> _x
Multiple conversation threads inside a BBS post means you 'view' the post as a feed, 1st Order comments as Posts, and 2nd oder...
Branches become trees and leaves become branches.
Building a single 'view' to handle shifting perspectives is not easy and OP seems to have at least thought this through with a proposal to have 2 different modes.
I'm looking forward to part_2 and (and maybe comparing it to my own conclusions ;}
That's why I'm suggesting the model is fundamentally wrong -- it shouldn't be represented as a tree (because conversation is a graph), and it shouldn't be represented as a "feed", because its infinitely recursive and a feed is specialized for a single depth.
The best representation is to flatten the graph (to produce a linear set of posts), and dynamically iterate from a post to its parents and children per user input. Inline post expansion ala 4chan[0] is the superior representation, because trying to decide ahead-of-time the best "hierarchy" to represent is the wrong question. The conversation is dynamic, and inter-related, and thus so too must be the UI. Obviously inline doesn't make sense on mobile, due to limited space, but its fundamentally more correct.
It's the same reason twitter conversations beyond a single thread are hard to follow -- you're iterating trees but you're trying to read a graph.
[0] http://freestyler.ws/images/styles_screenshot/1/84/42236/422...
The best representation is to flatten the graph (to produce a linear set of posts), and dynamically iterate from a post to its parents and children per user input. Inline post expansion ala 4chan[0] is the superior representation, because trying to decide ahead-of-time the best "hierarchy" to represent is the wrong question. The conversation is dynamic, and inter-related, and thus so too must be the UI. Obviously inline doesn't make sense on mobile, due to limited space, but its fundamentally more correct.
It's the same reason twitter conversations beyond a single thread are hard to follow -- you're iterating trees but you're trying to read a graph.
[0] http://freestyler.ws/images/styles_screenshot/1/84/42236/422...
So you made me finally go look closely at a _chan board and I get your points now. TBH I see the greentext screenshots a lot and they usually trigger a dyslexic response. But after playing a bit I totally agree the way they allow for rollover views of parent and grand parents while keeping the conversation flat & chronological is effective. Cross posting a comment to multiple parents totally breaks the tree/branch/leaf logic but I can see how useful it is tying similar tangents together and riffing feedback off of each other. TIL those boards are not just the raging dumpster fires of anarchy they get labeled as by us plain old normies.
Thanks for expanding my horizon !
Thanks for expanding my horizon !
> TIL those boards are not just the raging dumpster fires of anarchy they get labeled as by us plain old normies
I mean, they are, and I think it’s largely because of how effective the model is at enabling conversations (further enhanced by anonymity-by-default and low moderation). Twitter and Facebook threads/users of similar taste are utterly crippled by comparison, because conversations are really just announcements + virtue signaling. Even HN trees are similarly limited — half the conversations are 1-1 with no interjection.
You couldn’t have that kind of mess existing here even if you wanted to
I mean, they are, and I think it’s largely because of how effective the model is at enabling conversations (further enhanced by anonymity-by-default and low moderation). Twitter and Facebook threads/users of similar taste are utterly crippled by comparison, because conversations are really just announcements + virtue signaling. Even HN trees are similarly limited — half the conversations are 1-1 with no interjection.
You couldn’t have that kind of mess existing here even if you wanted to
This is my first submission to HN, though I've been reading for years. Please be kind, and I'd be delighted to hear your thoughts.
Holochain is currently testing a rudimentary p2p chat app running on a distributed network of hosts: https://blog.holochain.org/elemental-chat-is-live/
That could be an interesting space for you to shape and explore given the full p2p architecture tends to result in creative workarounds.
That could be an interesting space for you to shape and explore given the full p2p architecture tends to result in creative workarounds.
Thanks for sharing! I've thought about this idea as well while building Sqwok, and it's nice to see another perspective on it with clean visuals. I for public discovery views especially it could be valuable. One tradeoff to consider is how much info the user is being presented with at the same time. Multiple live chat streams could be overwhelming, but on the other hand done in the right way it could be very useful imo. Reposted to Sqwok, thanks! https://sqwok.im/p/Tc-jv369HXA8Ng
Thanks! To some degree the structure was the focus, because I believe the UI/UX would be the make or break for an attempt like this. I don't even think my designs would be a perfect implementation of this method.
Sqwok seems very interesting as well!
Sqwok seems very interesting as well!
Check out how Zulip does threads, it looks very similar to this. The main view shows a chronological list of posts along with its thread title, and you can click on one to show the entire thread as a normal chat. Even PMs show up in the feed interleaved with everything else.
Great visualizations and clear writing, well done. Keep up the writing!
Thank you for an interesting submission.
Super clear analysis and presentation of the core problem in group messaging today. Your visuals made the post so easy to read.
I’m not sure the conclusion applies for all cases. It may too easy to get lost in a thread behind an attachment.
Once I got used to it, iMessage’s UX has held up best (posting twice — once in focused thread and again in main thread). Not sure actual post has to happen in both places, but at least the activity should, otherwise there’s too high a risk to lose something or to have context switching set too high a friction bar.
I’m not sure the conclusion applies for all cases. It may too easy to get lost in a thread behind an attachment.
Once I got used to it, iMessage’s UX has held up best (posting twice — once in focused thread and again in main thread). Not sure actual post has to happen in both places, but at least the activity should, otherwise there’s too high a risk to lose something or to have context switching set too high a friction bar.
Thanks a lot, as I was writing/design I was concerned it would be a bit over-designed. I learned a lot for next time!
At a base concept, I agree. I think without a mature version of this idea, content could become lost rather quickly. A further iteration would likely be able to deal with some of those issues (say an sortable/algorithmic feed, and notifications tab). A way to filter/sort activity might be able to solve some of those issues.
At a base concept, I agree. I think without a mature version of this idea, content could become lost rather quickly. A further iteration would likely be able to deal with some of those issues (say an sortable/algorithmic feed, and notifications tab). A way to filter/sort activity might be able to solve some of those issues.
Have you tried the Teams tab in Microsoft Teams[1]? It features a concept similar to the proposed Content View (the ability to start a new thread and allowing users to reply within that thread, grouping contexts and preventing collisions). Unfortunately, IME, people tend to neglect/not notice this and will instead create a new thread just for their reply.
Creating an affordance to help users decide which type of message they want to send is key to increasing adoption here.
[1]: Screenshot here: https://techcommunity.microsoft.com/t5/microsoft-teams-blog/...
Creating an affordance to help users decide which type of message they want to send is key to increasing adoption here.
[1]: Screenshot here: https://techcommunity.microsoft.com/t5/microsoft-teams-blog/...
I have to use teams for work, and feel this whole approach, and as described in the article is pretty awful. I think Slack's threads are better. Just having the reply option, as Discord does is also most sufficent.
Having all this different thread containers causes the timing of the topic to get lost. I'll have to keep scrolling up to something important, and expand it, and then scroll to another on and expand it. then if I make any response, or want to see the latest that someone said, I need to lose my place again.
I haven’t seen the Teams implementation, though it sounds a bit like Slack’s approach. I’ll have to take a look.
Unfortunately creating another post/thread for previously mentioned content is a problem with most platforms (HN & Reddit included). Calling on older conversations is often as valuable (or more valuable) as the new conversation, so perhaps a way to link/reference the posts in a more formal way would be helpful.
Unfortunately creating another post/thread for previously mentioned content is a problem with most platforms (HN & Reddit included). Calling on older conversations is often as valuable (or more valuable) as the new conversation, so perhaps a way to link/reference the posts in a more formal way would be helpful.
Having used both, there's a big difference between Teams's approach and Slack's. Slack assumes a flat list where messages are in-line by default, but a thread can spawn out of an arbitrary one. Every message composed from the bottom bar of Teams creates a new thread, whether it has any replies or not.
Thanks for the insight. I’ll definitely take a look. I haven’t used many Microsoft services in the past couple of years, so I admit I’m a bit in the dark with their newer services.
Teams fixed this mostly by removing the text box in groups and replaced it with a button “New Conversation”
Content view is already implemented in basically all major chat platforms, you click an image in a chat and can scroll back through other images, or in some cases view all content in the chat in album grid view.
The threaded sub-conversations is a good point, but kind of changes the dynamic of what the group conversation is about. If you're responding to a sub-conversation above, how will other people be notified of that? Should everyone get a notification or just people involved in the sub-conversation?
In my mind that complicates things for users, as you have to find the group chat, then find the sub-conversation to comment on... it's just easier to put messages at the bottom in chronological order.
The threaded sub-conversations is a good point, but kind of changes the dynamic of what the group conversation is about. If you're responding to a sub-conversation above, how will other people be notified of that? Should everyone get a notification or just people involved in the sub-conversation?
In my mind that complicates things for users, as you have to find the group chat, then find the sub-conversation to comment on... it's just easier to put messages at the bottom in chronological order.
I tend to agree, and don't think this would make sense for super small conversations. I'm considering the larger groups, and also a foundational shift that could completely replace the likes of facebook groups.
It would no longer be a deeply simple chat, but from my observations the mental gymnastics required to understand large group chats (500+ users) are no longer simple either.
I don't think the other methods should entirely disappear, but perhaps there are some use-cases that would be better-suited using this method.
It would no longer be a deeply simple chat, but from my observations the mental gymnastics required to understand large group chats (500+ users) are no longer simple either.
I don't think the other methods should entirely disappear, but perhaps there are some use-cases that would be better-suited using this method.
I don't think this is a great approach. The main issue I see is that you need to decide if your message is a "chat" or a "post" when you send it. I don't think you will get a group of people to use it consistently, and I think it is often impossible to judge what type of conversation your message will spawn ahead of time. I think the better approach is to base the UI on how people respond, rather than having the sender select from the two interfaces up-front.
The intent is that this would be largely automatic. Videos, photos, gifs, links, etc., could automatically include a “comment” function (in-place of the current reply function).
If done manually (to a message, or group of messages) it could be within a menu (just like today’s long-tap to reply/react).
Hope that clarifies things. I had a section showing how I thought that could be better implemented, but I decided to save that for Part 2.
If done manually (to a message, or group of messages) it could be within a menu (just like today’s long-tap to reply/react).
Hope that clarifies things. I had a section showing how I thought that could be better implemented, but I decided to save that for Part 2.
I see, I missed that. In that case I have a follow up.
Why do you think that "media" is more likely to start a subthread than a regular message? It seems to me like this is unlikely to be a particularly effective distinction? Or is the intent that media + manual is close enough to perfect?
Why do you think that "media" is more likely to start a subthread than a regular message? It seems to me like this is unlikely to be a particularly effective distinction? Or is the intent that media + manual is close enough to perfect?
I am mostly assuming based off of my personal experience, Someone shares a link or photo, and everyone responds. User-testing would be fairly telling here, though the difference would mostly be "Should we show the comment button automatically or not?"
A message could become a post just as easily as users currently use "reply", instead they could "comment". Honestly in situations that use a "reply icon" the icon could even remain the same.
So yes, I think that media + manual is close enough to perfect.
A message could become a post just as easily as users currently use "reply", instead they could "comment". Honestly in situations that use a "reply icon" the icon could even remain the same.
So yes, I think that media + manual is close enough to perfect.
This feels like trying to turn IM in to Facebook. No one wants their group to become a link dump where you drop a video or news article and then leave. If the content isn’t discussion worthy or on topic, don’t dump it. No one likes chats which are just logs of someone’s YouTube history
The problem example highlights discordant or overlapping conversational flows and does not include posts or content sharing.
The proposed solution is to separate chat and posts/content sharing. In no way does that solve for the example problem.
Am I missing something here?
The proposed solution is to separate chat and posts/content sharing. In no way does that solve for the example problem.
Am I missing something here?
Cool thought.
I haven't figured out how to intelligently have a content-based news feed AND a serialized canonical feed of messages without making an algorithmic news feed.
Turns out writing news feed is a pain in the butt.
I haven't figured out how to intelligently have a content-based news feed AND a serialized canonical feed of messages without making an algorithmic news feed.
Turns out writing news feed is a pain in the butt.
And it depends on the platform’s motives if this feature were implemented. I could see the Apple iMessage approach simply “Sorting”, while FB Messenger would likely use a heavy-handed algorithm (depending on the size of the group).
If this concept were given room to evolve, I think both could coexist.
If this concept were given room to evolve, I think both could coexist.
I think we can involve the time element to make more sense of this without scanning all data, using an advanced AI or chopping the conversation up into multiple screens.
There's the chat in the past that you seldom need to look through and the chat right now. When looking through the past, we're scanning for more specific information as a summary and images and thumbnails tend to get in the way and take more time to scroll past. When we're actually moving with the chat we want to know everything that's happening now, all at once, with high visibility.
Clearly, content takes up too much space in chats, especially when scrolling back. What if all content in a chat collapsed after an interval of say, 5-10 minutes? You can re-expand it if you really want to see it but you're probably more interested in what someone said in text because that's the core medium of communication. If the whole topic of a chat is content, then vice versa, collapse contiguous blocks of messages instead. It would make sense to give moderators some power over collapsibility. The user could have some tools too such as keeping open all posts from friends, or certain individual users, or with certain keywords. Maybe there are some other rules of what to collapse and when that would make some sense, like a continuous chain of replies should generally stay open.
There's the chat in the past that you seldom need to look through and the chat right now. When looking through the past, we're scanning for more specific information as a summary and images and thumbnails tend to get in the way and take more time to scroll past. When we're actually moving with the chat we want to know everything that's happening now, all at once, with high visibility.
Clearly, content takes up too much space in chats, especially when scrolling back. What if all content in a chat collapsed after an interval of say, 5-10 minutes? You can re-expand it if you really want to see it but you're probably more interested in what someone said in text because that's the core medium of communication. If the whole topic of a chat is content, then vice versa, collapse contiguous blocks of messages instead. It would make sense to give moderators some power over collapsibility. The user could have some tools too such as keeping open all posts from friends, or certain individual users, or with certain keywords. Maybe there are some other rules of what to collapse and when that would make some sense, like a continuous chain of replies should generally stay open.
That's an interesting take, and I considered originally mentioning an AI that could auto-tag groups of messages. I honestly wrote this as a starter simply because I don't think there's nearly enough attention on innovation in chat-related spaces.
To some degree that means our present products do a good enough job, but at least from observation, I think those products lack a bit of out-of-the-box thinking that I tried to present here.
To some degree that means our present products do a good enough job, but at least from observation, I think those products lack a bit of out-of-the-box thinking that I tried to present here.
I'm all for innovating chat. Good on you for taking a step out of the armchair. I'll need to keep warming the seat for some time yet on that one.
I'm not sure that more fragmentation would be good.
Chats are linear because conversations are linear in time. Our brains have evolved to stay on top of linear group conversations.
Introducing too much of an opinionated interface would discourage tangents and off-topic banter, which I think is essential for a healthy group.
A different idea: delayed sending. If you want to have a conversation, but it doesn't need to be now, you can schedule your message to send in, say, 20 minutes, or whenever there is a pause.
If you want to implement a functional prototype, I would recommend hacking on top of one of the open source matrix clients [1], the open spec has experimental support for nested chat rooms ("spaces") [2] and threads [3].
[1] https://matrix.org/clients/
[2] https://github.com/matrix-org/matrix-doc/blob/kegan/spaces-s...
[3] https://github.com/matrix-org/matrix-doc/blob/kegan/msc/thre...
Introducing too much of an opinionated interface would discourage tangents and off-topic banter, which I think is essential for a healthy group.
A different idea: delayed sending. If you want to have a conversation, but it doesn't need to be now, you can schedule your message to send in, say, 20 minutes, or whenever there is a pause.
If you want to implement a functional prototype, I would recommend hacking on top of one of the open source matrix clients [1], the open spec has experimental support for nested chat rooms ("spaces") [2] and threads [3].
[1] https://matrix.org/clients/
[2] https://github.com/matrix-org/matrix-doc/blob/kegan/spaces-s...
[3] https://github.com/matrix-org/matrix-doc/blob/kegan/msc/thre...
I think that’s of valid concern. Removing users from the immediacy of a chat into a comment section could be jarring. Facebook seems to have bridged that gap by adding “... is Typing” directly to comments sections, to make them feel more alive.
A hacked together proof of concept would be fantastic. I’ve used Matrix/Element, so it’s not completely unfamiliar territory.
A hacked together proof of concept would be fantastic. I’ve used Matrix/Element, so it’s not completely unfamiliar territory.
There is an insight around messaging which I think this is getting at, or at least which I've been particularly excited about:
1. It is useful to be able to navigate conversations by topic (and sub-topics etc.). AKA making the search/navigation/sense-making activities easy.
AND
2. It is useful to be able to just respond to what was seen last in a single stream. AKA making the responding/reacting activities easy.
No one has gotten this quite right yet.
Manual threading and nesting don't do this well, especially for graph structures. The ability in some applications to respond and reach to particular messages helps a little; but isn't coupled with a navigation view, and you can only respond to one 'message unit' at a time. (Though I also am not sure that the navigation interaction needs to be an entirely separate view as shown here.)
I expect powerful language models to dramatically change this landscape, doing the magic for people of creating the navigation/conversation type of interactions (e.g. automatically inferring/suggesting "what is being responded to" for each message, thus developing a conversational graph (which can then be summarized and shown in a variety of ways).
I'm curious who is innovating on this? (All I know of is https://quill.chat).
1. It is useful to be able to navigate conversations by topic (and sub-topics etc.). AKA making the search/navigation/sense-making activities easy.
AND
2. It is useful to be able to just respond to what was seen last in a single stream. AKA making the responding/reacting activities easy.
No one has gotten this quite right yet.
Manual threading and nesting don't do this well, especially for graph structures. The ability in some applications to respond and reach to particular messages helps a little; but isn't coupled with a navigation view, and you can only respond to one 'message unit' at a time. (Though I also am not sure that the navigation interaction needs to be an entirely separate view as shown here.)
I expect powerful language models to dramatically change this landscape, doing the magic for people of creating the navigation/conversation type of interactions (e.g. automatically inferring/suggesting "what is being responded to" for each message, thus developing a conversational graph (which can then be summarized and shown in a variety of ways).
I'm curious who is innovating on this? (All I know of is https://quill.chat).
And each message could have a subject. Then the main window would just show the subjects, and you could look at the full text of only the ones that interest you.
Oh, right. That's email.
Oh, right. That's email.
The final proposal comes down to a separation between "chat room" & "posts", chat where there is social babble, and posts, where notable & distinct things go.
I feel like this is already embodied in chat rooms that can pin messages. That can designate: "here are the active articles of discussion." This reflects my own bias, that it's not about having difference places, but more about ways to raise up content, highlight it, create views & indexes of the information we browse through.
I feel like this is already embodied in chat rooms that can pin messages. That can designate: "here are the active articles of discussion." This reflects my own bias, that it's not about having difference places, but more about ways to raise up content, highlight it, create views & indexes of the information we browse through.
True, and I do like pinned messages. I don’t think a “Featured Post/Content” necessarily needs to be removed here.
The intent with this approach is to condense the regular conversation pieces, whereas the pinned messages typically contain content that changes less frequently.
The intent with this approach is to condense the regular conversation pieces, whereas the pinned messages typically contain content that changes less frequently.
[deleted]
This is mostly what Google Chat looks like.
We need to force people to use respond-to (rather than just write a message) then show threads and your place in them beautifully and conveniently so they would enjoy that.
Fun fact: this can be achieved with e-mail, no need to invent new protocols.
Fun fact: this can be achieved with e-mail, no need to invent new protocols.
No thanks. I like the current model as used in whatsapp. Every new message appears at the bottom, you can reply to individual messages, and there is a separate media view if you want to browse photos and videos and documents.
As I recall, wasn't Google Wave something like the proposals in the article?
I remember joining a couple waves on day one, quickly devolved to chaos. The collaborative editing was cool and I'm sure Google cannibalized that for Google Docs et al
In the last few weeks there was a chat app posted here (a Show HN?), that lets you retroactively create threads by selecting some existing messages. Wish I could remember the name, seems like a good feature.
Look, maybe I’m gonna sound like the adult in the room who says the party’s over, or even the get off my lawn grandpa, but here goes.
Real time is mostly a gimmick. It’s in the same category as video games and entertainment. A lot goes into making it performant and scalable but for getting things done in life it’s a net negative.
1. Those realtime notifications that interrupt your family time and dates, because the people on the other side have unreasonable expectations of immediacy
2. That 200th person today who entered your chat and said “Hey everyone!” adding zero new information.
3. The 30th time someone asked a basic question that was already addressed and could have been easily found in an FAQ or database or threaded view
4. The literally 27,503 messages you missed (many including “hi” etc.) that may as well have not been written at all as far as you’re concerned because you’re not going to scroll and even see them
5. By the time someone comes who can answer your question, it could have scrolled off the screen, but if you’re lucky they might go back in history, find it and tag you
5a. Chat is totally unstructured. So many people make plans via chat, it’s ridiculous. A marketplace or event list should not be negotiated via chat any more than chess games should all be blindfold chess with only the list of moves and having everyone reconstruct the position in their mind.
6. There is no goal, chat can go on endlessly, like those 9273837 comments about some publicly shared meme on facebook of which 2/3 say the same thing. Combine that with an algorithm that prioritizes “engagement” (ie ad revenue for the social network) and we wonder why our political discourse is beoken. We even began to create https://rational.app to fix political discourse.
7. It’s bad for OPSEC and anonymity also. People have been busted as an online pseudonym by cutting their wifi and watching the person go offline. How nice are those “presence” indicators eh? It was a huge undertaking at Facebook just so you could casually know when someone was online and ignoring you.
8. The fact is, that people will cut corners creating content if you let them. And on average there are far more readers of the content than writers. Making people slow down and write paragraphs and edit their thoughts before hitting Return is better than making them write one line spastically
Now consider threaded discussions, tagging, and so on. The conversation is a tree. Each thread can have its own governance, and can be easily hosted by whoever started it. Things can be combined into an FAQ, in fact that’s how Stackoverflow works. And that will make every answer better, and every question has a better chance of being answered.
We are ON SUCH A SITE RIGHT NOW. Any part of the tree can be collapsed, or expanded. It’s easy to navigate. It can be represented in many other ways too.
You know what it doesn’t have? All of the above things. It doesn’t even ping you when someone replied to your message, which is the most addictive — err, sorry, “engaging” - thing of all.
Now go to your Telegram and look at those channels you’re in with 30,000 members. How many missed messages do you see? 7,000? Go ahead come in and interact with 0.1% of the channel that happens to be there the time. You said hi? You asked a question and no one around had any expertise? You left for and hour and came back to see another 500 messages, wasting time trying to scroll back to where you were? Yeah. That was realtime chat. Just like Facebook Likes and Cryptokitties, it is a gimmick that has benefitted almost no one.
Real time is mostly a gimmick. It’s in the same category as video games and entertainment. A lot goes into making it performant and scalable but for getting things done in life it’s a net negative.
1. Those realtime notifications that interrupt your family time and dates, because the people on the other side have unreasonable expectations of immediacy
2. That 200th person today who entered your chat and said “Hey everyone!” adding zero new information.
3. The 30th time someone asked a basic question that was already addressed and could have been easily found in an FAQ or database or threaded view
4. The literally 27,503 messages you missed (many including “hi” etc.) that may as well have not been written at all as far as you’re concerned because you’re not going to scroll and even see them
5. By the time someone comes who can answer your question, it could have scrolled off the screen, but if you’re lucky they might go back in history, find it and tag you
5a. Chat is totally unstructured. So many people make plans via chat, it’s ridiculous. A marketplace or event list should not be negotiated via chat any more than chess games should all be blindfold chess with only the list of moves and having everyone reconstruct the position in their mind.
6. There is no goal, chat can go on endlessly, like those 9273837 comments about some publicly shared meme on facebook of which 2/3 say the same thing. Combine that with an algorithm that prioritizes “engagement” (ie ad revenue for the social network) and we wonder why our political discourse is beoken. We even began to create https://rational.app to fix political discourse.
7. It’s bad for OPSEC and anonymity also. People have been busted as an online pseudonym by cutting their wifi and watching the person go offline. How nice are those “presence” indicators eh? It was a huge undertaking at Facebook just so you could casually know when someone was online and ignoring you.
8. The fact is, that people will cut corners creating content if you let them. And on average there are far more readers of the content than writers. Making people slow down and write paragraphs and edit their thoughts before hitting Return is better than making them write one line spastically
because its so farsi call
far sickle
I mean farcical! Stupid autocomplete
Haha LOL
Lmao smiley face yea
hehe
Now consider threaded discussions, tagging, and so on. The conversation is a tree. Each thread can have its own governance, and can be easily hosted by whoever started it. Things can be combined into an FAQ, in fact that’s how Stackoverflow works. And that will make every answer better, and every question has a better chance of being answered.
We are ON SUCH A SITE RIGHT NOW. Any part of the tree can be collapsed, or expanded. It’s easy to navigate. It can be represented in many other ways too.
You know what it doesn’t have? All of the above things. It doesn’t even ping you when someone replied to your message, which is the most addictive — err, sorry, “engaging” - thing of all.
Now go to your Telegram and look at those channels you’re in with 30,000 members. How many missed messages do you see? 7,000? Go ahead come in and interact with 0.1% of the channel that happens to be there the time. You said hi? You asked a question and no one around had any expertise? You left for and hour and came back to see another 500 messages, wasting time trying to scroll back to where you were? Yeah. That was realtime chat. Just like Facebook Likes and Cryptokitties, it is a gimmick that has benefitted almost no one.
[deleted]
of course there's room for improvement or a rethinking of how stuff is organized but chat isn't (1) organized and it's (2) a people problem.
Mainly (2). It's been a people problem, an lack of attention to organization principles and UIs since the beginning of digital time. You just can't try to have all this stuff inside one app interface/system. The chaos of chat simply can't become a repository of non-linear/knowledge without extraction/organzation after.
Mainly (2). It's been a people problem, an lack of attention to organization principles and UIs since the beginning of digital time. You just can't try to have all this stuff inside one app interface/system. The chaos of chat simply can't become a repository of non-linear/knowledge without extraction/organzation after.
Isn't this a slightly less general version of Zulip? I wish more products would adopt that topic model, it works really well for bridging the overlapping conversation puzzle.
I hadn’t heard of Zulip before today, but there are definitely some valid overlaps.
I agree, I think that regardless of methodology, some way to deal with the problem is welcome.
I want to enjoy using group chats, especially as they continue to mature.
I agree, I think that regardless of methodology, some way to deal with the problem is welcome.
I want to enjoy using group chats, especially as they continue to mature.
I am working on something for group messages but not in a linear fashion. I've taken different approach to the OP though.
Take a look at https://cocoon.com
Can we just resurrect Google Wave please? Only half joking, it's threading was very interesting.
I'd be happy if only my messaging app would let me block messages sent to a particular group.
Why does this site ask for VR permission?
Does it? I don't have any integrations to activate something like that AFAIK. This is my first self-developed site, I'm using Gatsby,js, so it's possible they're trying to do some heavy-lifting for VR that I'm not familiar with?
Did he just discover threaded comments? Reddit?
The problem doesn’t seem so much to be with the real time participants of the conversation. The problem is if you weren’t there to begin with. Reading chat logs is probably like attempting to read the transcript of your family holiday dinner. It would be nonsense. You’d have no sense of time, no sense of delay, no sense of conversational flurry, etc. As a passive “participant” reading the conversation, you’re disengaged from the very construction that led to it at all, so in practice you lose a sense of context or continuity.
So these proposed solutions are asking you to do more than communicate. They’re asking you to also organize. And the problem with asking users to organize in addition to communicate is that it’s easier to just not organize.