Es gab schon viele Tools, die versprachen, „Dinge auszuwählen, die meine Aufmerksamkeit verdienen“, aber keines hat wirklich gut zu mir oder meinem Team gepasst. Ich frage mich, was bei Struct anders ist.
Beim Ansehen des Videos auf der Struct-Landingpage sind mir ein paar Fragen gekommen: Kanäle wirken wie der Ausgangspunkt für Threads/Feeds — sind sie einfach nur ein Konzept zum Gruppieren von Nutzern, und kann man in Kanälen auch chatten? Falls Nutzer nur die Threads sehen, die im Echtzeit-Feed erscheinen, frage ich mich auch, wie man das Problem löst, dass Threads mit viel Aktivität, aber wenig Signal Platz einnehmen und wichtige, aber weniger aktive Threads verdrängen. Tags sind wichtig fürs Filtern, aber wie bei JIRA-Tags werden sie leicht unübersichtlich durch ähnliche, aber unterschiedliche Textgruppen — gibt es eine Möglichkeit, das zu verwalten? Wie geht ihr mit unabhängig von verschiedenen Nutzern zum selben Thema erstellten Threads um? Und zu 1:1-Privatgesprächen würde ich auch gern mehr wissen, die kamen im Video nur sehr kurz vor. Das Tool selbst sieht auf jeden Fall so aus, als hätte es Potenzial.
In Struct sind Kanäle nur Gruppen von Personen, und man bestimmt den Zugriff auf einen Thread, indem man einen Kanal erwähnt, so als würde man Nutzer direkt ansprechen.
Es ist nicht so aufgebaut, dass man in einen Kanal hineingeht und dort chattet. Im Feed hat jeder Thread eine feste Höhe, daher können sehr aktive Threads nicht unbegrenzt Platz einnehmen, und es ist geplant, Funktionen zum Archivieren oder Stummschalten von Threads für eine bestimmte Zeit hinzuzufügen. Tags haben eine Begrenzung pro Thread und werden genutzt, um Kontext hinzuzufügen und benutzerdefinierte Feeds zu erstellen; wir verwenden sie auch zur Verfolgung von Aufgabenprioritäten, also fast wie ein leichtgewichtiges Task-Management-System. Ähnliche Tags sollen zusammengeführt werden können, und es wird auch Kontrolle möglich sein, etwa dass nur Moderatoren neue Tags anlegen dürfen. Ähnliche Threads können zusammengeführt werden, und wir bereiten auch eine Funktion vor, mit der man einzelne Chats aus einem Thread auswählen und in einen neuen Thread ausgliedern kann; die Verknüpfungen zwischen Threads sollen dabei erhalten bleiben. Für private Gespräche erwähnt man einfach die gewünschten Nutzer; wenn man @struct erwähnt, entsteht ein DM mit dem Bot, und wenn man sich selbst erwähnt, wird ein „Self-DM“ für TODOs oder Notizen erstellt. In einem Markt voller Chat-Plattformen kann Struct wie „noch eine Chat-App“ wirken, aber ich habe sie gebaut, weil andere Plattformen Dinge, von denen ich dachte, sie müssten sie selbstverständlich tun, auch nach Jahren des Wartens nicht umgesetzt haben.
Das Problem ist, dass jeder möchte, dass seine eigenen Anrufe nicht gefiltert werden, während er die der anderen filtern möchte.
Wenn jemand meine Aufmerksamkeit will, findet er immer weiter Wege, sie an sich zu reißen, zum Beispiel indem er einen neuen Thread erstellt.
Das ist der erste Slack-Konkurrent seit Langem, der mich wirklich interessiert, und es sieht so aus, als hätte er die Richtung richtig gewählt. Mein Gesamteindruck nach dem Video ist positiv, aber irgendwie wirkte es wie ein weniger persönliches Tool.
Slack-Räume fühlten sich wie digitale „Räume“ an, während Struct eher wie ein schwarzes Brett im Büro wirkt. Wenn ein Unternehmen komplett auf Struct setzt und ich dort neu anfangen würde, hätte ich als ersten Eindruck das Gefühl, dass es schwieriger wäre, persönliche Verbindungen zu Kollegen aufzubauen. Ich weiß nicht genau, warum, aber beim Ansehen der Demo hatte ich dieses Gefühl. Wenn ich an das Kommunikationschaos zurückdenke, das ich früher als Engineering-Leiter im Silicon Valley erlebt habe, denke ich allerdings auch, dass ich so ein Tool in meiner letzten Firma gern gehabt hätte.
Als Gründer denke ich zusammen mit Jason viel über genau diesen Punkt nach. Es ist schwer, die Balance zu finden zwischen einer unruhigen linken Leiste mit allen Namen und dem Gefühl, sich mit anderen im selben Raum zu befinden.
Feed-basierte Plattformen werden oft sehr asynchron und fast forenartig. Deshalb sollte das Design des Echtzeit-Feeds in Struct eher das Gefühl betonen: „Diese Leute sind gerade jetzt in diesem Raum und sprechen unmittelbar miteinander.“ Die Momente, in denen ein neuer Thread auftaucht oder ein neuer Chat im Feed erscheint, sind ziemlich unterhaltsam und spannend. Wenn man eine Liste der gerade online befindlichen Personen zeigt, könnte das eher dazu anregen, ein Gespräch zu beginnen, und selbst nur sichtbar zu machen, dass andere gerade teilnehmen, kann helfen. Es gibt auf jeden Fall noch Raum, um besser darauf zu optimieren, dass Gespräche tatsächlich entstehen.
Ich glaube, man könnte für das Onboarding neuer Mitarbeitender nützliche Threads erstellen, die immer bereitstehen.
Trotzdem ist es für jede Organisation wichtig, dass sich neue Leute warm willkommen fühlen, und in Organisationen mit hohem Remote-Anteil gilt das umso mehr. Man könnte Räume wie @random, @club-channels und @annoucements schaffen, um lustige Links oder ankündigungsartige Informationen zu teilen und als Ort zu nutzen, an dem man Kolleginnen und Kollegen kennenlernt. Intern bei @struct ist vieles stark arbeitsorientiert, und wir bauen gern Dinge, aber wir brauchen auch Spaß.
Wirklich gut. Mir gefällt die Idee, Kanäle beizubehalten und gleichzeitig fokussierte Threads zu nutzen, und auch das Design ist gelungen.
Ich würde aber gern den langfristigen Plan verstehen. Bevor ich viele Daten in so einen Dienst gebe, möchte ich wissen, dass das nicht wieder so ein VC-finanziertes Produkt ist, das hochgezogen, verkauft und dann aufgegeben wird.
Ich habe vor, Struct langfristig weiter zu betreiben. Wir sind ein kleines Team aus drei Leuten — Backend, Designer, Frontend — und bauen kein kapitalintensives Produkt.
Auf der Roadmap, auf die wir uns freuen, stehen Sprach-/Videoanrufe und Webinare, Spam-Kontrolle für Communities, Verbesserungen bei AI-Bots und Erinnerungsfunktionen samt Kostensenkung sowie AI-Antworten auf Basis in Struct geteilter, indexierter Dokumente unter Beibehaltung der Zugriffskontrolle. Struct ist deshalb interessant, weil es gleichzeitig Team-Chat, Community-Chat, Task-Management-System, ChatGPT, persönliche TODO-Liste und eine öffentlich indexierbare Wissensdatenbank ersetzen kann. Es ist erstaunlich, was möglich wird, wenn man dem System vertrauen kann, dass es nichts vergisst.
Sieht vielversprechend aus. Ich würde mir aber wünschen, dass ihr die Preisangabe noch einmal überarbeitet.
Es ist zu kompliziert, das selbst durchzurechnen, und ich hätte Sorge, dass die Kosten explodieren, wenn Diskussionen plötzlich explodieren. Beispiele und eine Darstellung in Tabellenform wären hilfreich. Nutzer sollten nicht erst nachdenken müssen. Ich frage mich auch, warum Struct-Namen mindestens 6 Zeichen lang sein müssen. 4 sollten doch reichen, und internationale Standards mit mehr als 3 Zeichen gibt es doch inzwischen auch nicht mehr. Und beim macOS-App-Icon hätte ich gern eine einfarbige Variante wie bei anderen Apps.
Wir haben Daten aus Organisationen, die Struct bereits im Einsatz haben. Kurz gesagt: Struct ist deutlich günstiger als Slack.
Die monatliche Grundgebühr beträgt 9,97 US-Dollar, und abgerechnet wird nicht nach Nutzerzahl, Thread-Zahl oder Chat-Zahl, sondern nur nach AI-Nutzung. Im Grundpreis sind 200.000 Token enthalten, was für kleine Organisationen ausreicht, die es nur für Thread-Titel und Zusammenfassungen verwenden. Bei realen Nutzern liegt der Durchschnittsverbrauch von Typesense in diesem Bereich, und Apache Druid nutzt etwa 400.000 Token pro Monat. 1.000 Token kosten 3 Cent, also kommen 200.000 Token auf etwa 6 US-Dollar zusätzlich zur Grundgebühr. Beide nutzen Struct als Wissensdatenbank. Wenn wir die Abrechnung verpflichtend einführen, werden Nutzer ein monatliches Ausgabenlimit setzen können, damit es keine unerwarteten Rechnungen gibt, und die Kosten nach der Grundgebühr lassen sich so niedrig halten, wie man möchte.
Glückwunsch zum Produkt. Ich bin alt genug, mich noch an die Zeit der klassischen Foren zu erinnern, und ehrlich gesagt wirkte es auf mich wie eine Wiederentdeckung des Forums
Gemeint ist die Thread-Struktur, bei der etwas bei Updates nach oben rückt. Der große Unterschied ist wohl, dass die UI eher nach Chat/Facebook aussieht und Foren statisch von Administratoren strukturiert wurden, während man bei Struct nicht wirklich eine threadartige Strukturierung im Stil von Ordnern sieht, wie sie in großen Organisationen mit vielen gleichzeitigen Themen nötig wäre. E-Mail lässt sich dagegen zumindest bis zu einem gewissen Grad nach „Unterhaltungen“ bündeln und zusätzlich in persönlichen Ordnern strukturieren. Dass überall auch noch „AI“ dranhängt, fühlt sich inzwischen ermüdend an. Dynamische Zusammenfassungen von Threads sind an sich sinnvoll, aber wenn ein Thread chatartig simpel ist, braucht man keine Zusammenfassung, und wenn er so lang ist wie E-Mail oder ein Forum, bin ich nicht sicher, wie gut das in der Praxis wirklich funktioniert. Deshalb bin ich unsicher, ob das einfach eine chatartige Marketing-App mit AI-Buzzword ist oder ob ich etwas übersehe, das sich grundlegend von Forum-Threads oder E-Mail-Konversationen unterscheidet
Struct ist stark von Discourse inspiriert und eine eigenständige Mischung aus Forum und Chat-Anwendung
Jedes Forum, einschließlich E-Mail, hat Threads und Feeds, aber Foren sind asynchron und nicht um Echtzeit-Chat herum entworfen. Die Schwierigkeit bei der Übertragung von Thread- und Feed-Konzepten auf eine Chat-Plattform ist, dass alles in Echtzeit funktionieren muss, und genau das versucht Struct zu lösen. Der Aussage „Wenn es Chat ist, braucht man keine Zusammenfassung“ kann ich nicht ganz zustimmen. Ich habe an genug endlosen Unterhaltungen teilgenommen, und selbst in kleinen Teams gibt es Threads mit Hunderten von Nachrichten. Zusammenfassungen helfen tatsächlich sehr, und schon allein ein Titel macht einen Feed deutlich verständlicher. Man kann Threads mit Tags strukturieren und Feeds um diese Tags herum aufbauen, und das entspricht den Ordnern. Das erinnert mich daran, wie Menschen bei Gmail erst verstehen mussten, dass Labels den SMTP-Ordnern entsprechen. Der Unterschied zwischen Struct-Threads und Discourse-Threads ist, dass Struct kurze, in Echtzeit hin- und hergehende Kommunikation betont, während Discourse lange, durchdachte Einzelbeiträge betont. Ersteres ist Chat, Letzteres ein Forum. Dass Struct so schwer zu gestalten ist, liegt auch am Gleichgewicht zwischen Struktur, Wissen und Echtzeit
Die AI-Zusammenfassung-Funktion, die es kurz bei Discord gab, war ziemlich komisch
Sie hat immer den Kern der Diskussion komplett verfehlt und absurde Zusammenfassungen erzeugt, über die man stundenlang lachen konnte
Der Satz „Bilde Feeds aus den Threads des CEO, um dich an der neuesten Vision und den Zielen des Unternehmens auszurichten. Spring mit der passenden Antwort in Gespräche ein und hol dir die verdiente Beförderung“ hat mir ein bitteres Lächeln entlockt
Am Ende wird man wieder daran erinnert, dass nicht entscheidend ist, was man tut, sondern wer es sieht
Als Ingenieur, der beim Aufbau eines Startups Management gelernt hat, würde ich sagen: Arbeite, aber sorge auch dafür, dass diese Arbeit sichtbar ist
Bei meinem ersten Job bei Google habe ich einfach immer weiter gebaut und hatte Schwierigkeiten zu vermitteln, warum das, was ich machte, wichtig war. Mein erster Manager beförderte das ganze Team außer mir, und das tut noch heute weh. Als ich Team und Manager wechselte, wurde mir gesagt, dass ich zwei Stufen unter dem Level eingestuft worden war, auf dem ich eigentlich hätte sein sollen. Die Schlussfolgerung ist: Geh in solche Gespräche hinein. Man muss nicht aufdringlich sein, aber man sollte Präsenz zeigen
Ist es nicht auch Aufgabe eines Managers, auf dem Laufenden zu sein, woran die Mitarbeiter arbeiten?
Mitarbeiter dazu zu ermutigen, Zeit darauf zu verwenden, sich selbst gegenüber ihren Vorgesetzten zu vermarkten, ist auch nicht im Interesse des Unternehmens. Man sieht das oft, aber für mich ist das meist ein Zeichen dafür, dass viele Manager in diesem Punkt ihren Job nicht gut machen
Ich sollte die Fehlermeldung etwas aufräumen. Es geht nicht darum, OpenAI zu verbergen, sondern einfach darum, sie ansprechender darzustellen
Ich mag OpenAI. GPT-4 funktioniert wirklich gut. Ich habe auch günstigere andere Modelle ausprobiert, aber die Qualität war einfach nicht genauso gut
Manchmal überlege ich, ob ich im Router einfach die .ai-Domains blockieren soll, bis sich dieser Trend wieder normalisiert
Ernsthaft gesagt: Dieses Produkt sah wirklich interessant aus, bis ich die Formulierung „…und AI“ gesehen habe. Wahrscheinlich bin ich einfach nicht die Zielgruppe
Zusammenfassen ist eine Aufgabe, die AI wirklich gut beherrscht, deshalb finde ich dieses Produkt großartig
Mich würde interessieren, welche Technologien verwendet wurden. Ob intern dgraph oder badger genutzt wird, ob das Hosting bei den Big 3 läuft oder anderswo, ob Kubernetes eingesetzt wird, ob Elastic Search verwendet wird. Und auch, ob Struct ein Tool ist, das Slack/Discord online abgreift, oder ob es jetzt oder künftig eine eigenständige Chat-App werden soll
Der Tech-Stack ist Go, Postgres, OpenAI, React/Next.JS, Loops.so, Imgproxy, Microsoft-E5-Embeddings, Typesense-Suche, Figma, Framer und Hetzner-Server
Der größte Kostenfaktor ist OpenAI, und für Embeddings wird nicht OpenAI, sondern Microsoft E5 verwendet. Typesense wird für die Suche eingesetzt und ist auch Nutzer von Struct. Badger statt Postgres zu verwenden, wäre nicht richtig gewesen, aber für andere Anwendungsfälle wird Badger in Betracht gezogen. Intern werden viel ristretto und roaring bitmaps verwendet. Struct hat eine ziemlich gute Slack-Integration und kann wie ein Slack-Interface genutzt werden. So in der Art: Die Kollegen benutzen Slack und ich antworte in Struct, ein bisschen wie Superhuman für Gmail. Die Discord-Integration ist ebenfalls gut, und beides wird von Open-Source-Unternehmen genutzt, um aus Slack-/Discord-Gesprächen öffentliche Wissensdatenbanken zu erstellen. [1]: https://github.com/struct-chat/embedding
Ich frage mich manchmal, ob wir Produktivität nicht auf die falsche Weise optimieren. Statt Tools zum Management von Kommunikationsrauschen könnte es größere Vorteile bringen, Kommunikation von vornherein zu reduzieren und trotzdem die notwendige Arbeit gut zu erledigen.
Ich würde zum Beispiel nicht optimieren wollen, damit sich Dutzende von Meetings besser nachverfolgen lassen. Ich hätte lieber weniger, dafür effektivere Meetings.
Stimme ich voll zu. Die Branche steckt im Paradigma des „Zauberknopfs“ fest, und AI macht nur dann coole Dinge, wenn man diesen Knopf drückt.
Wenn AI aus einer Meeting-Aufzeichnung automatisch eine Zusammenfassung erstellen kann, gibt es keinen Grund, warum sie nicht auch die nächsten Schritte oder Action Items nachverfolgen könnte. Wenn der nächste Schritt ist, dass Janine ein Meeting mit Carlos ansetzt, warum sollte AI dann nicht Carlos kontaktieren und beim Terminieren helfen? Im Moment denken wir zu klein.
Dass wir Meetings reduzieren sollten, ist plausibel. Auch Chat-Plattformen oder Tools wie Loom haben letztlich das Ziel, die Zahl notwendiger Meetings zu verringern.
Allerdings lässt sich auch Metcalfes Gesetz nicht vermeiden. Der Großteil moderner Arbeit findet im Team statt, und wenn die Teamgröße N ist, trägt man Kommunikationskosten von O(N^2). Ich glaube nicht, dass die Gesamtkommunikation sinken wird; wir brauchen die richtigen Tools, um sie effektiver zu bewältigen.
Großartig. Discord ist das Schlechteste, wenn es darum geht, Informationen zu durchsuchen und Threads zu verfolgen.
Es fühlt sich so an, als würde man dieselbe Frage immer wieder beantworten.
Discord wird am Ende wohl ebenfalls LLM-basierte Suche hinzufügen, so wie Slack AI es angekündigt hat, und dann verschwindet dieses Problem.
Dieses Produkt scheint eher auf Slack oder Teams abzuzielen als auf Discord.
1 Kommentare
Hacker-News-Kommentare
Es gab schon viele Tools, die versprachen, „Dinge auszuwählen, die meine Aufmerksamkeit verdienen“, aber keines hat wirklich gut zu mir oder meinem Team gepasst. Ich frage mich, was bei Struct anders ist.
Beim Ansehen des Videos auf der Struct-Landingpage sind mir ein paar Fragen gekommen: Kanäle wirken wie der Ausgangspunkt für Threads/Feeds — sind sie einfach nur ein Konzept zum Gruppieren von Nutzern, und kann man in Kanälen auch chatten? Falls Nutzer nur die Threads sehen, die im Echtzeit-Feed erscheinen, frage ich mich auch, wie man das Problem löst, dass Threads mit viel Aktivität, aber wenig Signal Platz einnehmen und wichtige, aber weniger aktive Threads verdrängen. Tags sind wichtig fürs Filtern, aber wie bei JIRA-Tags werden sie leicht unübersichtlich durch ähnliche, aber unterschiedliche Textgruppen — gibt es eine Möglichkeit, das zu verwalten? Wie geht ihr mit unabhängig von verschiedenen Nutzern zum selben Thema erstellten Threads um? Und zu 1:1-Privatgesprächen würde ich auch gern mehr wissen, die kamen im Video nur sehr kurz vor. Das Tool selbst sieht auf jeden Fall so aus, als hätte es Potenzial.
Es ist nicht so aufgebaut, dass man in einen Kanal hineingeht und dort chattet. Im Feed hat jeder Thread eine feste Höhe, daher können sehr aktive Threads nicht unbegrenzt Platz einnehmen, und es ist geplant, Funktionen zum Archivieren oder Stummschalten von Threads für eine bestimmte Zeit hinzuzufügen. Tags haben eine Begrenzung pro Thread und werden genutzt, um Kontext hinzuzufügen und benutzerdefinierte Feeds zu erstellen; wir verwenden sie auch zur Verfolgung von Aufgabenprioritäten, also fast wie ein leichtgewichtiges Task-Management-System. Ähnliche Tags sollen zusammengeführt werden können, und es wird auch Kontrolle möglich sein, etwa dass nur Moderatoren neue Tags anlegen dürfen. Ähnliche Threads können zusammengeführt werden, und wir bereiten auch eine Funktion vor, mit der man einzelne Chats aus einem Thread auswählen und in einen neuen Thread ausgliedern kann; die Verknüpfungen zwischen Threads sollen dabei erhalten bleiben. Für private Gespräche erwähnt man einfach die gewünschten Nutzer; wenn man @struct erwähnt, entsteht ein DM mit dem Bot, und wenn man sich selbst erwähnt, wird ein „Self-DM“ für TODOs oder Notizen erstellt. In einem Markt voller Chat-Plattformen kann Struct wie „noch eine Chat-App“ wirken, aber ich habe sie gebaut, weil andere Plattformen Dinge, von denen ich dachte, sie müssten sie selbstverständlich tun, auch nach Jahren des Wartens nicht umgesetzt haben.
Wenn jemand meine Aufmerksamkeit will, findet er immer weiter Wege, sie an sich zu reißen, zum Beispiel indem er einen neuen Thread erstellt.
Das ist der erste Slack-Konkurrent seit Langem, der mich wirklich interessiert, und es sieht so aus, als hätte er die Richtung richtig gewählt. Mein Gesamteindruck nach dem Video ist positiv, aber irgendwie wirkte es wie ein weniger persönliches Tool.
Slack-Räume fühlten sich wie digitale „Räume“ an, während Struct eher wie ein schwarzes Brett im Büro wirkt. Wenn ein Unternehmen komplett auf Struct setzt und ich dort neu anfangen würde, hätte ich als ersten Eindruck das Gefühl, dass es schwieriger wäre, persönliche Verbindungen zu Kollegen aufzubauen. Ich weiß nicht genau, warum, aber beim Ansehen der Demo hatte ich dieses Gefühl. Wenn ich an das Kommunikationschaos zurückdenke, das ich früher als Engineering-Leiter im Silicon Valley erlebt habe, denke ich allerdings auch, dass ich so ein Tool in meiner letzten Firma gern gehabt hätte.
Feed-basierte Plattformen werden oft sehr asynchron und fast forenartig. Deshalb sollte das Design des Echtzeit-Feeds in Struct eher das Gefühl betonen: „Diese Leute sind gerade jetzt in diesem Raum und sprechen unmittelbar miteinander.“ Die Momente, in denen ein neuer Thread auftaucht oder ein neuer Chat im Feed erscheint, sind ziemlich unterhaltsam und spannend. Wenn man eine Liste der gerade online befindlichen Personen zeigt, könnte das eher dazu anregen, ein Gespräch zu beginnen, und selbst nur sichtbar zu machen, dass andere gerade teilnehmen, kann helfen. Es gibt auf jeden Fall noch Raum, um besser darauf zu optimieren, dass Gespräche tatsächlich entstehen.
Trotzdem ist es für jede Organisation wichtig, dass sich neue Leute warm willkommen fühlen, und in Organisationen mit hohem Remote-Anteil gilt das umso mehr. Man könnte Räume wie @random, @club-channels und @annoucements schaffen, um lustige Links oder ankündigungsartige Informationen zu teilen und als Ort zu nutzen, an dem man Kolleginnen und Kollegen kennenlernt. Intern bei @struct ist vieles stark arbeitsorientiert, und wir bauen gern Dinge, aber wir brauchen auch Spaß.
Wirklich gut. Mir gefällt die Idee, Kanäle beizubehalten und gleichzeitig fokussierte Threads zu nutzen, und auch das Design ist gelungen.
Ich würde aber gern den langfristigen Plan verstehen. Bevor ich viele Daten in so einen Dienst gebe, möchte ich wissen, dass das nicht wieder so ein VC-finanziertes Produkt ist, das hochgezogen, verkauft und dann aufgegeben wird.
Auf der Roadmap, auf die wir uns freuen, stehen Sprach-/Videoanrufe und Webinare, Spam-Kontrolle für Communities, Verbesserungen bei AI-Bots und Erinnerungsfunktionen samt Kostensenkung sowie AI-Antworten auf Basis in Struct geteilter, indexierter Dokumente unter Beibehaltung der Zugriffskontrolle. Struct ist deshalb interessant, weil es gleichzeitig Team-Chat, Community-Chat, Task-Management-System, ChatGPT, persönliche TODO-Liste und eine öffentlich indexierbare Wissensdatenbank ersetzen kann. Es ist erstaunlich, was möglich wird, wenn man dem System vertrauen kann, dass es nichts vergisst.
Sieht vielversprechend aus. Ich würde mir aber wünschen, dass ihr die Preisangabe noch einmal überarbeitet.
Es ist zu kompliziert, das selbst durchzurechnen, und ich hätte Sorge, dass die Kosten explodieren, wenn Diskussionen plötzlich explodieren. Beispiele und eine Darstellung in Tabellenform wären hilfreich. Nutzer sollten nicht erst nachdenken müssen. Ich frage mich auch, warum Struct-Namen mindestens 6 Zeichen lang sein müssen. 4 sollten doch reichen, und internationale Standards mit mehr als 3 Zeichen gibt es doch inzwischen auch nicht mehr. Und beim macOS-App-Icon hätte ich gern eine einfarbige Variante wie bei anderen Apps.
Die monatliche Grundgebühr beträgt 9,97 US-Dollar, und abgerechnet wird nicht nach Nutzerzahl, Thread-Zahl oder Chat-Zahl, sondern nur nach AI-Nutzung. Im Grundpreis sind 200.000 Token enthalten, was für kleine Organisationen ausreicht, die es nur für Thread-Titel und Zusammenfassungen verwenden. Bei realen Nutzern liegt der Durchschnittsverbrauch von Typesense in diesem Bereich, und Apache Druid nutzt etwa 400.000 Token pro Monat. 1.000 Token kosten 3 Cent, also kommen 200.000 Token auf etwa 6 US-Dollar zusätzlich zur Grundgebühr. Beide nutzen Struct als Wissensdatenbank. Wenn wir die Abrechnung verpflichtend einführen, werden Nutzer ein monatliches Ausgabenlimit setzen können, damit es keine unerwarteten Rechnungen gibt, und die Kosten nach der Grundgebühr lassen sich so niedrig halten, wie man möchte.
Glückwunsch zum Produkt. Ich bin alt genug, mich noch an die Zeit der klassischen Foren zu erinnern, und ehrlich gesagt wirkte es auf mich wie eine Wiederentdeckung des Forums
Gemeint ist die Thread-Struktur, bei der etwas bei Updates nach oben rückt. Der große Unterschied ist wohl, dass die UI eher nach Chat/Facebook aussieht und Foren statisch von Administratoren strukturiert wurden, während man bei Struct nicht wirklich eine threadartige Strukturierung im Stil von Ordnern sieht, wie sie in großen Organisationen mit vielen gleichzeitigen Themen nötig wäre. E-Mail lässt sich dagegen zumindest bis zu einem gewissen Grad nach „Unterhaltungen“ bündeln und zusätzlich in persönlichen Ordnern strukturieren. Dass überall auch noch „AI“ dranhängt, fühlt sich inzwischen ermüdend an. Dynamische Zusammenfassungen von Threads sind an sich sinnvoll, aber wenn ein Thread chatartig simpel ist, braucht man keine Zusammenfassung, und wenn er so lang ist wie E-Mail oder ein Forum, bin ich nicht sicher, wie gut das in der Praxis wirklich funktioniert. Deshalb bin ich unsicher, ob das einfach eine chatartige Marketing-App mit AI-Buzzword ist oder ob ich etwas übersehe, das sich grundlegend von Forum-Threads oder E-Mail-Konversationen unterscheidet
Jedes Forum, einschließlich E-Mail, hat Threads und Feeds, aber Foren sind asynchron und nicht um Echtzeit-Chat herum entworfen. Die Schwierigkeit bei der Übertragung von Thread- und Feed-Konzepten auf eine Chat-Plattform ist, dass alles in Echtzeit funktionieren muss, und genau das versucht Struct zu lösen. Der Aussage „Wenn es Chat ist, braucht man keine Zusammenfassung“ kann ich nicht ganz zustimmen. Ich habe an genug endlosen Unterhaltungen teilgenommen, und selbst in kleinen Teams gibt es Threads mit Hunderten von Nachrichten. Zusammenfassungen helfen tatsächlich sehr, und schon allein ein Titel macht einen Feed deutlich verständlicher. Man kann Threads mit Tags strukturieren und Feeds um diese Tags herum aufbauen, und das entspricht den Ordnern. Das erinnert mich daran, wie Menschen bei Gmail erst verstehen mussten, dass Labels den SMTP-Ordnern entsprechen. Der Unterschied zwischen Struct-Threads und Discourse-Threads ist, dass Struct kurze, in Echtzeit hin- und hergehende Kommunikation betont, während Discourse lange, durchdachte Einzelbeiträge betont. Ersteres ist Chat, Letzteres ein Forum. Dass Struct so schwer zu gestalten ist, liegt auch am Gleichgewicht zwischen Struktur, Wissen und Echtzeit
Sie hat immer den Kern der Diskussion komplett verfehlt und absurde Zusammenfassungen erzeugt, über die man stundenlang lachen konnte
Der Satz „Bilde Feeds aus den Threads des CEO, um dich an der neuesten Vision und den Zielen des Unternehmens auszurichten. Spring mit der passenden Antwort in Gespräche ein und hol dir die verdiente Beförderung“ hat mir ein bitteres Lächeln entlockt
Am Ende wird man wieder daran erinnert, dass nicht entscheidend ist, was man tut, sondern wer es sieht
Bei meinem ersten Job bei Google habe ich einfach immer weiter gebaut und hatte Schwierigkeiten zu vermitteln, warum das, was ich machte, wichtig war. Mein erster Manager beförderte das ganze Team außer mir, und das tut noch heute weh. Als ich Team und Manager wechselte, wurde mir gesagt, dass ich zwei Stufen unter dem Level eingestuft worden war, auf dem ich eigentlich hätte sein sollen. Die Schlussfolgerung ist: Geh in solche Gespräche hinein. Man muss nicht aufdringlich sein, aber man sollte Präsenz zeigen
Mitarbeiter dazu zu ermutigen, Zeit darauf zu verwenden, sich selbst gegenüber ihren Vorgesetzten zu vermarkten, ist auch nicht im Interesse des Unternehmens. Man sieht das oft, aber für mich ist das meist ein Zeichen dafür, dass viele Manager in diesem Punkt ihren Job nicht gut machen
runForThread.executeReq.Get.messages: executeReq.client.Do: Get "[https://api.openai.com/v1/threads/thread_*******/messages?li...](<https://api.openai.com/v1/threads/…;)": context deadline exceeded (Client.Timeout exceeded while awaiting headers)Hoffentlich kommen irgendwann neue Produkte heraus, die ohne OpenAI-Abhängigkeit auskommen
Ich mag OpenAI. GPT-4 funktioniert wirklich gut. Ich habe auch günstigere andere Modelle ausprobiert, aber die Qualität war einfach nicht genauso gut
.ai-Domains blockieren soll, bis sich dieser Trend wieder normalisiertErnsthaft gesagt: Dieses Produkt sah wirklich interessant aus, bis ich die Formulierung „…und AI“ gesehen habe. Wahrscheinlich bin ich einfach nicht die Zielgruppe
Zusammenfassen ist eine Aufgabe, die AI wirklich gut beherrscht, deshalb finde ich dieses Produkt großartig
Mich würde interessieren, welche Technologien verwendet wurden. Ob intern dgraph oder badger genutzt wird, ob das Hosting bei den Big 3 läuft oder anderswo, ob Kubernetes eingesetzt wird, ob Elastic Search verwendet wird. Und auch, ob Struct ein Tool ist, das Slack/Discord online abgreift, oder ob es jetzt oder künftig eine eigenständige Chat-App werden soll
Der größte Kostenfaktor ist OpenAI, und für Embeddings wird nicht OpenAI, sondern Microsoft E5 verwendet. Typesense wird für die Suche eingesetzt und ist auch Nutzer von Struct. Badger statt Postgres zu verwenden, wäre nicht richtig gewesen, aber für andere Anwendungsfälle wird Badger in Betracht gezogen. Intern werden viel ristretto und roaring bitmaps verwendet. Struct hat eine ziemlich gute Slack-Integration und kann wie ein Slack-Interface genutzt werden. So in der Art: Die Kollegen benutzen Slack und ich antworte in Struct, ein bisschen wie Superhuman für Gmail. Die Discord-Integration ist ebenfalls gut, und beides wird von Open-Source-Unternehmen genutzt, um aus Slack-/Discord-Gesprächen öffentliche Wissensdatenbanken zu erstellen. [1]: https://github.com/struct-chat/embedding
Ich frage mich manchmal, ob wir Produktivität nicht auf die falsche Weise optimieren. Statt Tools zum Management von Kommunikationsrauschen könnte es größere Vorteile bringen, Kommunikation von vornherein zu reduzieren und trotzdem die notwendige Arbeit gut zu erledigen.
Ich würde zum Beispiel nicht optimieren wollen, damit sich Dutzende von Meetings besser nachverfolgen lassen. Ich hätte lieber weniger, dafür effektivere Meetings.
Wenn AI aus einer Meeting-Aufzeichnung automatisch eine Zusammenfassung erstellen kann, gibt es keinen Grund, warum sie nicht auch die nächsten Schritte oder Action Items nachverfolgen könnte. Wenn der nächste Schritt ist, dass Janine ein Meeting mit Carlos ansetzt, warum sollte AI dann nicht Carlos kontaktieren und beim Terminieren helfen? Im Moment denken wir zu klein.
Allerdings lässt sich auch Metcalfes Gesetz nicht vermeiden. Der Großteil moderner Arbeit findet im Team statt, und wenn die Teamgröße N ist, trägt man Kommunikationskosten von O(N^2). Ich glaube nicht, dass die Gesamtkommunikation sinken wird; wir brauchen die richtigen Tools, um sie effektiver zu bewältigen.
Großartig. Discord ist das Schlechteste, wenn es darum geht, Informationen zu durchsuchen und Threads zu verfolgen.
Es fühlt sich so an, als würde man dieselbe Frage immer wieder beantworten.