[mrjn]

Struct is quite inspired by Discourse. It's a unique blend of forum and chat application.

So, you know, every forum, including email, has threads and feed. But, forums are asynchronous, not designed around real-time chat. The challenge when applying concept of threads and feeds to a chat platform is that you need to make it real-time. And that's the hard thing that Struct is tackling -- with the real-time feed design that we have.

I disagree a bit about, "if it's chat, it doesn't need summary". I've been part of enough conversations which go on and on, to know that's not true. Even with the small team we run, we have threads which have like 100s of chat messages, going back and forth. Having summaries really help.

Or, at the very least, you'd appreciate the titles, so your feed would make more sense.

You can structure your threads using tags, and create feed around those tags. That'd be the equivalent of "folders". (Reminds me of when Gmail came out and people had to learn to map their labels on SMTP folders)

The difference in a Struct thread, v/s say a Discourse thread would be this. Struct emphasizes short form, real-time, back and forth communication. Discourse emphasizes long form, well-thought through, one-off posts. Former is chat, latter is forum.

This is long topic, but something I think about a lot. Designing Struct is hard exactly because of this balance between structure, knowledge and being real-time.

[olivierduval]

OK, so the point is the "real time" interactions

Actually, at work, I'm either in 2 situations:

- I need a quick answer for a simple problem ==> chat (because it's more about getting a simple info and I need it now if possible, or the sooner)

- I need a complete/correct/thoughtfull answer ==> email (because I need someone to really think about it before answering and that person is not available all the time and has other things to do too... so quality of answer is worth waiting)

It may happen that complex email need some clarifications... but if the subject is complex, it usually requires a meeting

It may happen too that a simple answer lead to a complex question... but then we're back at email.

So, I'm not sure that your tool would fit my way of working and/or the places I work for. Moreover, I'm quite sure that "realtime" is one of the WORST possible way of working because it's giving other people a way to manage your time at work (interrupting, etc.)

[mrjn]

Real-time platforms cause interruptions, yes. But, that's where we are today with Slack.

So, we're starting off from that point. Let's take real-time chat platforms, and reimagine how we can make them more efficient. More useful. Less noisy. That's the idea for Struct.

The list of people we email is different from the list of people we chat with. In a team, that means, team comms happen on chat platform. And external comms happen on emails. Within a team using a chat platform, it's unlikely that people would chat, and then say, hold on, let me send you an email. If that happens, that's very rare.

What's a lot more likely is you jump from a chat conversation into a video call. Hence, the need for a nice integration with video service (like Slack has huddle).

So, for a certain set of people (your team or community), you're going to use the chat platform. And therefore, the chat platform should be built to enable conversations with good retrieval and focus -- so it can be used for complex conversations. Struct hits that pretty well.