5 ms·
I think the reason linear feeds remain popular is because they emulate conversation, and nothing else. Conversation something everybody knows how to do. Our bra
by reikonomusha 6y ago
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.
- jackson1442 6y agoYeah, 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 6y agoI 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 6y agoThat’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?
- antihero 6y ago> 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?)
- spurgu 6y agoAgreed 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.
- jacobolus 6y agoSlack 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.
- spurgu 6y agoYeah 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.
- lmm 6y agoYeah, 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.
- PurpleFoxy 6y agoThe 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.
- bigiain 6y ago> Ultimately, how many people actually care about chat backlogs. <cynical voice> The same people who want to wear Google Glass in bars...
- dasyatidprime 6y ago> 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.
- TeMPOraL 6y ago> 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: 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? Substitute _, ___, _v_ and VVV for e.g. a subtle-colored graphic polygon that grows with time, so that the user wouldn't have to parse it.
- tw04 6y agoI 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.
- jerf 6y agoI'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.)