[olivierduval]

Congrats for your product !

BTW: I'm old enough to remember the "forums' days"... and actually, it really seemed to me that you just rediscovered forum (you know... threads that are bumped when there an update)

The only major differences I saw was:

- the UI is more "chat-like" / "facebook-like"

- forums where statically structured by an admin... but it looks like there no real way to structure your threads in folder or things like that (important on big orgs with lots of different subjects concurrently)

On the other side, mails may be (more or less) structured by "conversation" (sadly it's not a strong standard so not reliable) and conversation may be structured by personal folders

- there's "AI" and that's quite tiring these days. I see the point of having a dynamic summary of a thread... but

    * either your threads are 'chat-like' so with simple content... and no summary is needed

    * or your threads are 'mail/forum-like'... and I'm not sure how it will work (sincerly)

Sooooooo... I'm not sure to know what to think about it. Is it "just" a marketing 'chat-like' with 'AI buzzword' app ? Or did I miss something that make it really fundamentally different from forum threads or email conversation ?

[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.

[olivierduval]

Actually, I think that a real features for chat would be the ability to allow "different speeds":

- some questions requires "urgent" answers (for example: missing info in a meeting)

- some interactions may be processed "in the flow", during the day, when time is available

- some interactions are "human noise", people just chatting

Right now, with teams & others, everything may be "urgent" so you'll have to check and see (so interrupting your work)

Moreover, when it's not urgent, you may decide to answer later... and just forget it (because it's not a new message anymore)

So maybe that's a place where AI could help: show only what's urgent... and reminds at a later time for other kinds of chats

Just an idea

[mrjn]

The reason Slack and Teams feels so "urgent", is because there's little going back to reply to an older conversation. Everything is so ephemeral on these platforms, that either you reply now, or it's a goner (slight exaggeration, but mostly true).

Struct's feed system is naturally designed to surface latest, unread conversations. So even if when I've been away for days, I just come back and go thread by thread, like cleaning an inbox. It's a lot smoother system, and you miss nothing.

[creshal]

> I see the point of having a dynamic summary of a thread...

That was a really cool feature in Discord, for a while: The AI always completely missed the point of the discussion and made hilariously awful summaries that provided entertainment for hours.

[mrjn]

It's hard to do summaries for chats in channels. Just not enough focus in them to be useful.

Could also be the model that they were using. I've tried a few and found GPT4 to be most accurate. GPT4-Turbo is still a question mark.