[HN Gopher] The Future of Group Messaging
___________________________________________________________________
The Future of Group Messaging
Author : thejarren
Score : 56 points
Date : 2021-03-09 17:29 UTC (5 hours ago)
(HTM) web link (thejarren.com)
(TXT) w3m dump (thejarren.com)
| sbuttgereit wrote:
| As I recall, wasn't Google Wave something like the proposals in
| the article?
| josh2600 wrote:
| 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.
| thejarren wrote:
| 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.
| vlokshin wrote:
| 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.
| thejarren wrote:
| 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.
| cglong wrote:
| 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/...
| ntw1103 wrote:
| 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.
| PurpleFoxy wrote:
| Teams fixed this mostly by removing the text box in groups and
| replaced it with a button "New Conversation"
| thejarren wrote:
| 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.
| cglong wrote:
| 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.
| thejarren wrote:
| 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.
| Macha wrote:
| Why does this site ask for VR permission?
| setr wrote:
| 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.
| eximius wrote:
| This is mostly what Google Chat looks like.
| rektide wrote:
| 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.
| thejarren wrote:
| 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.
| Causality1 wrote:
| I'd be happy if only my messaging app would let me block messages
| sent to a particular group.
| ajcp wrote:
| 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?
| stephen_dev wrote:
| I am working on something for group messages but not in a linear
| fashion. I've taken different approach to the OP though.
| avivo wrote:
| 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).
| thejarren wrote:
| 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.
| holler wrote:
| 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
| treelovinhippie wrote:
| 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.
| ergl wrote:
| 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.
| siruva07 wrote:
| Great ideas and spectacular visuals. Good luck finding a new
| position!
| thejarren wrote:
| Thank you very much!
| amackera wrote:
| Great visualizations and clear writing, well done. Keep up the
| writing!
| Daho0n wrote:
| Thank you for an interesting submission.
| luplex wrote:
| 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...
| thejarren wrote:
| 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.
| intrasight wrote:
| 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?
| kevincox wrote:
| 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.
| thejarren wrote:
| 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.
| PurpleFoxy wrote:
| 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
| kevincox wrote:
| 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?
| samprotas wrote:
| 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/
| flaburgan wrote:
| Did he just discover threaded comments? Reddit?
| robto wrote:
| 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.
| thejarren wrote:
| 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.
| reikonomusha wrote:
| I think the reason linear feeds remain popular is because they
| emulate conversation, and nothing else. Conversation something
| everybody knows how to do. Our brains know how to manage
| relatively complex and disorganized discourse, some better than
| others.
|
| 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.
| PurpleFoxy wrote:
| 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.
| dasyatidprime wrote:
| > 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.
| antihero wrote:
| > 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?)
| thejarren wrote:
| 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?
| jackson1442 wrote:
| 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.
| kevincox wrote:
| 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.
| thejarren wrote:
| Agreed. I like the tree of threaded comments like Reddit/HN
| much more. Theoretically the comments in posts could use
| that structure.
| EccentricBunny wrote:
| I think the reason chat applications like Discord or Slack are
| usually 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.
___________________________________________________________________
(page generated 2021-03-09 23:01 UTC)