Nino: Integrierter Workspace mit 18 Apps für Dokumente, Tabellen, Formulare, Websites, Chat und mehr
(nino.app)- Nino ist ein modularer Workspace für Profis, der Dokumente, Tabellen, Präsentationen, Formulare, Drive, Kalender, Websites, Blogs, Chat, Meetings und mehr in einer Oberfläche bündelt
- Informationen werden auf Seiten- und Blockebene wiederverwendet; Page Sourcing, Page Embed, Block Embed und Block Mirror verbinden dieselben Inhalte mit mehreren Arbeitsabläufen
- Offline-Anzeige und -Bearbeitung, schnelles Öffnen auf Basis lokaler Speicherung sowie integrierte Suche über alle Module vereinfachen den Zugriff auf Materialien, auch wenn viele Apps hinzukommen
- Auch im kostenlosen Plan werden unbegrenzte Mitglieder und Gäste unterstützt; enthalten sind Echtzeit-Anwesenheitsanzeige, Live-Cursor, Channels, Chat, externe Sharing-Bereiche und unbegrenzte Videokonferenzen
- Website- und Blog-Publishing, Custom Domains, 1-Klick-Rollback, Meta-Tag-SEO, ein CDN in über 200 Städten sowie serverseitige Metrikanalyse bündeln Arbeitswerkzeuge und Publishing-Funktionen an einem Ort
Modularer Workspace und Einstieg
- Nino bündelt mehrere Arbeits-Apps in einer einheitlichen Oberfläche und unterstützt Interoperabilität auf Blockebene
- Zu den angebotenen Modulen gehören Doc, Sheet, Slide, Form, Drive, Calendar, List, Site, Blog, Chat, Meet, Collab und weitere
- Die Einstiegsoptionen sind Download Nino for Linux und Use the web app
- Die grundlegende Nutzung konzentriert sich darauf, Arbeitsmaterialien, die über mehrere Module verteilt sind, schnell zu finden und zu öffnen
- Offline-Modus: Anzeigen und Bearbeiten ohne Internetverbindung möglich
- Schnelles Öffnen: sofortiger Zugriff auf Basis lokaler Speicherung möglich
- Integrierte Suche: alle Module auf einmal durchsuchbar
Struktur zur Wiederverwendung von Seiten und Blöcken
- Die Kernstruktur besteht darin, Seiten und Blöcke an anderen Stellen erneut zu verwenden
- Page sourcing: eine Seite auf andere Weise anzeigen
- Page embed: eine Seite mit einer anderen Seite synchronisieren
- Block embed: einen Block mit einer anderen Seite synchronisieren
- Block mirror: einen Block innerhalb derselben Seite synchronisieren
- Beispiel-Workflows werden in Projektmanagement, Wissensmanagement und Datenbankmanagement unterteilt
- Projektmanagement kombiniert Collection, Board, Todo, Grid und Channel, um Aufgaben anzulegen, nach Verantwortlichen zu filtern sowie Dashboards und Diskussionen aufzubauen
- Wissensmanagement bettet Seiten, Blöcke, Diagramme und Datei-Blöcke in Notebook, Slide, Doc und Drive ein
- Datenbankmanagement verbindet mit Sheet, Form, Site und Calendar Umfragedaten, Formulare, Kampagnen-Websites und Kampagnenkalender
- Für Custom Workflows werden Text, Code, Formeln, Dateien, Bilder, Videos, Audio, Tabellen, Kommentare, Link-Embeds, Page Embeds, Block Embeds, Block Mirrors, Karten-Embeds, Buttons, Diagramme und mehr verwendet
Zusammenarbeit und Publishing-Funktionen
- Die Kollaborationsfunktionen zielen sowohl auf interne Teams als auch auf externe Zusammenarbeitsbereiche ab
- Auch im kostenlosen Plan werden unbegrenzte Mitglieder und Gäste unterstützt
- Nutzer auf einer Seite lassen sich in Echtzeit sehen, und mit Live-Cursorn kann gemeinsam bearbeitet werden
- Channel bietet unbegrenzte Gruppengrößen, Chat bietet 1:1- oder Gruppengespräche, Collab bietet externe Sharing-Bereiche, und Meet bietet unbegrenzte Videokonferenzen
- Die Publishing-Funktion bietet einen No-Code-Flow, um Seiten als Website oder Blog zu veröffentlichen
- Mit Version control ist ein 1-Klick-Rollback möglich
- Nutzung einer Custom Domain oder einer nino.page-Subdomain möglich
- SEO auf Basis benutzerdefinierter Meta-Tags und ein CDN in über 200 Städten werden bereitgestellt
- Unterstützung für integrierte Seiten inklusive Snapshots eingebetteter Blöcke
- Die Analyse erfasst nur serverseitige Metriken und verhindert so Datenverluste durch Browser-Erweiterungen
Datenschutz- und Sicherheitsprinzipien sowie langfristiger Plan
- Datenschutz- und Sicherheitsprinzipien sind darauf ausgerichtet, kein App-Tracking zu betreiben und nur funktionale Cookies sowie Fehlerberichte zu verwenden
- Produktverbesserungen stützen sich auf direktes Nutzerfeedback
- Der Dienst läuft auf einer
.app-Domain und verwendet ausschließlich HTTPS-Verbindungen
- Der langfristige Plan ist, Hunderte von Modulen für Wissensarbeit zu entwickeln
- Aufgelistet werden Doc, Sheet, Slide, Form, Drive, Calendar, Collection, Notebook, Channel, Gallery, Canvas, Board, Todo, Grid, List, Site, Blog, Chat, Meet und Collab
1 Kommentare
Meinungen auf Hacker News
Das Datenmodell von Anfang an richtig hinzubekommen, ist die größte technische Herausforderung. Wenn das Produkt erst einmal groß ist, ist es extrem schwer zu ändern, und ohne Vorsicht kann das zu ausufernden JSONB-Spalten, duplizierten Daten, verwaisten Zeilen und miserabler Performance führen.
Kunden werden in Docs größere Elemente speichern wollen, als man vielleicht erwartet; dabei kann die Versuchung entstehen, sie inline abzulegen, statt sie in einen externen Speicher wie S3 auszulagern.
Chat braucht im Grunde eine eigene Datenbank. Discord nutzt Scylla, Slack nutzt Vitess auf MySQL, aber die Zugriffsmuster bei Chat unterscheiden sich in ihren Anforderungen völlig von anderen Speichern.
Wenn man eine Active-Active-Konfiguration betreibt, sollte man einen Plan haben, irgendwann davon wegzukommen. Ohne atemberaubend teure Hardware skaliert das nicht.
Das sage ich aus Erfahrung als DBRE bei einem Wettbewerber.
Offline-Speicherung ist cool, aber es wirkt auch ein bisschen so, als würde etwas wie Ditto [0] verwendet. Wenn ich mich richtig erinnere, nutzt es intern MyRocksDB; direkte Erfahrung habe ich nicht, kenne aber einige sehr starke Leute, die bei Ditto arbeiten.
[0]: https://ditto.live
Integration und Modularität können eine Lösung sein, aber Menschen gehen nicht ohne Problem auf Lösungseinkauf. „App-Chaos“ ist für die meisten ein zu abstraktes Problem.
Es muss zuerst klar sein, ob es schwierig ist, Google Docs in Slack zu teilen, ob Unternehmen unter mangelnder Integration von SharePoint und Teams leiden, ob dieses Tool das besser macht, ob es ähnlich, aber günstiger ist, oder ob es zuverlässiger ist.
Wenn man nicht gleich vorne definiert, welche konkreten Probleme Menschen tatsächlich haben und wie diese integrierte Lösung sie behebt, wird es niemanden interessieren.
Das zweite große Problem ist, dass man ein konsistentes Interface-Design-Team braucht, das die verschiedenen Apps benutzerfreundlicher macht als die jeweiligen Einzellösungen. Die Tatsache, dass beliebte Endnutzer-Apps kaum als entwicklergetriebene FOSS-Projekte entstehen – außer bei Projekten, die von Organisationen mit professionell angestellten Designern betreut werden, wie Firefox, Blender oder Signal –, zeigt die Grenzen entwicklerzentrierter UI/UX.
Das sage ich als jemand, der mehrere Jahre Vollzeitentwickler war, Tausende Stunden zu FOSS beigetragen hat und danach ins Design gewechselt ist.
Wirkt wie ein klassisches Beispiel für „Ingenieure sind keine Produktverantwortlichen“.
Es wäre schön, wenn man Software so bauen könnte, dass sich das Datenmodell leicht ändern lässt.
Dafür müsste man alle Datenabhängigkeiten im System nachverfolgen können, aber es gibt noch kein Tool, das so etwas leistet. Alle wählen eine Standarddatenbank, aber für diesen Zweck ist keine davon wirklich brauchbar.
Die App selbst wirkt auf den ersten Blick sehr beeindruckend, aber wenn Feedback gewünscht ist, ist aus Produktsicht viel zu unklar, was sie ist und warum sie wichtig ist
Aus Sicht von Business-Nutzern ist nicht klar, wie man sie verwenden soll und warum man sich dafür interessieren sollte
Der Text auf der Startseite zählt Funktionen auf, etwa „Nino ist eine Sammlung von Apps, die auf Blockebene in einer einheitlichen Oberfläche interoperabel sind …“. Verglichen mit monday.com oder Asana, die bei Use Cases und konkreter Anwendung beginnen, ist der Unterschied groß
Monday startet mit „Was möchten Sie verwalten?“ und zeigt Kategorien wie Work Management, Sales CRM und Dev; klickt man auf einen Eintrag, wird konkret erklärt, wie es hilft
Ich wollte es bei einem Spaziergang etwa fünf Minuten ausprobieren und habe die Web-App versucht, aber iOS Safari wurde nicht unterstützt. Nachdem ich die iOS-App heruntergeladen und mich registriert hatte, landete ich in einer komplett leeren App, ohne Onboarding, Templates/Beispiele oder eine Möglichkeit, vorhandene Google Sheets zu importieren und die Skalierung einzuschätzen
Ich habe eine Datenquelle und ein paar Felder hinzugefügt, war aber verwirrt, und inzwischen war der Spaziergang vorbei
https://www.youtube.com/watch?v=u4ZoJKF_VuA
Ich empfehle auch, das Buch zu lesen
Nach dieser Theorie sollte die Reihenfolge Why, How, What sein, aktuell beginnt ihr aber beim What
Ich habe den Kern des Produkts noch nicht vollständig erfasst, aber man könnte es etwa so neu formulieren: „Verschwenden Sie keine Zeit damit, Dokumente, E-Mails und Chats in mehreren Systemen zu suchen. Zahlen Sie nicht für 20 Einzweck-Services, nur um Ihr Unternehmen zu betreiben“
Wenn alle Informationen an einem Ort liegen, lassen sie sich unternehmensweit leichter finden und teilen; durch die Kombination von Dokumenten, Chats, Spreadsheets, Formularen usw. kann man Werkzeuge bauen, die die eigenen Prozesse und Denkweisen unterstützen, statt sich der Logik bestehender Apps anzupassen
Man könnte sagen, Nino ermöglicht es, mit modularen Bausteinen schnell individuelle Abläufe zu erstellen und die benötigten Tools sowie alle Informationen an einem Ort zu haben
Es erinnert auch an OLE / OpenDoc auf dem Desktop, also daran, Excel-Sheets und Access-Formulare in ein Word-Dokument einzubetten. Wenn das möglich ist, könnte das eine ziemlich beeindruckende Demo sein
Allerdings könnte es etwas anderes sein, eine solche ganzheitliche Vision von Anfang an anzunehmen, als zunächst fokussiert zu starten und später in eine Ausweitung des Umfangs hineingedrängt zu werden
Viele sagen, ein Unternehmen stirbt, wenn es sich nicht spezialisiert, aber hier scheint es gerade eine gute Chance zu geben, einen Bereich zu besetzen, den niemand wirklich gut abdeckt. Zum Beispiel ein vertikal integriertes Dokumentenmanagementsystem für Use Cases wie ISO 9001
Use Case 1 ist Dokumentenmanagement. Man muss Dokumentversionen „veröffentlichen“, diese Versionen dauerhaft sichtbar machen und Dokumentkennungen gemäß den Namensregeln des Unternehmens automatisch erzeugen und in das Dokument einfügen können. Eine Dokument-ID könnte etwa SOP-2401001 lauten
Wenn ein Dokument veröffentlicht ist, sollte es schreibgeschützt sein, und Artefakte wie eine exportierte PDF-Kopie oder eine signierte Kopie sollten zusammen mit dem veröffentlichten Dokument abgelegt werden können
Use Case 2 ist Dokumentensiloisierung. Einer der schwierigsten Teile des Dokumentenmanagements ist es, Formulare für Prozesse zu erstellen und den Leuten beizubringen, die Dokumentenverwaltung dieses Formulars nach dem Ausfüllen nicht zu zerstören
Ich wollte immer, dass beim Ausfüllen eines Formulars automatisch eine Kopie erstellt, eine neue Dokument-ID vergeben und das Ganze in einem Silo mit anderen Formularen desselben Typs gesammelt wird
Durch Integration mit einer Automatisierungsplattform könnte das Ausfüllen eines Formulars eine E-Mail an jemanden auslösen; noch ausgefeilter wäre es, dokumentenspezifische Workflows zu definieren und den Business-Prozess visuell neben dem Dokument darzustellen
Mein erster Eindruck nach ein paar Minuten Nutzung ist, dass es sehr viele leistungsstarke Funktionen geben könnte, es in App und Website aber fast keine Anleitung und kein Onboarding gibt, sodass man nicht weiß, was man tun und wie man es lernen soll
Ich habe es auf dem Mac installiert und wollte einen Satz von Kontakt-Datensätzen mit Basisfeldern wie Name, Telefonnummer und Geburtstag hinzufügen und diese Datensätze dann aus einem anderen Modul abfragen
Die App gibt aber keinerlei Hinweise, wie das funktionieren soll. Beim Öffnen sieht man nur einen leeren Tab, und ich musste verschiedene Controls anklicken, um herauszufinden, wie man Module hinzufügt
Ich wusste nicht, welches Modul ich verwenden sollte, um abfragbare Datensätze hinzuzufügen, also habe ich Board ausprobiert
Nachdem ich Board hinzugefügt hatte, konnte ich den ersten Datensatz eintragen, aber es schien keine Möglichkeit zu geben, einen zweiten hinzuzufügen. Es gab Spalten namens „None“ und „Unnamed“, und der erste Kontakt landete in „None“. Der „+“-Button in der Ecke fügte eine neue Spalte hinzu
Schließlich zog ich den Datensatz von „None“ nach „Unnamed“, woraufhin „None“ verschwand und nur „Unnamed“ übrig blieb; erst dann konnte ich weitere Datensätze hinzufügen
Ich werde noch ein wenig weiter damit herumspielen, aber es hat Grenzen, zu erwarten, dass die Leute das vorgesehene Nutzungsmodell selbst herausfinden. Es gibt viele Module, aber ich weiß nicht, wie sie miteinander verbunden sind, und eine Beispielkonfiguration für ein fiktives Team wäre sehr hilfreich
Sieht wirklich großartig aus
Ich würde es gern ausprobieren, aber dafür müsste ich bestehende Tools und Workflows ersetzen. Aus Nutzersicht möchte man das nicht tun, wenn man nicht sowohl Dateneigentum als auch Application-Hosting sicherstellen kann
Falls Nino nicht erfolgreich ist und das Produkt eingestellt wird, frage ich mich, wie man dann weiter auf die eng gekoppelten proprietären Daten zugreifen kann. Ich würde wissen wollen, ob Self-Hosting möglich ist, ob der Quellcode veröffentlicht wird, ob das Dokumentformat offen ist und ob es eine Möglichkeit gibt, Schäden zu vermeiden, falls man es begeistert einführt und es dann scheitert
Wichtig ist auch, wie man die Daten wieder herausbekommt, wenn man sie eingegeben hat und das Produkt nicht passt
Man kann zwar werkzeugspezifische Vorteile verlieren, etwa die Integration zwischen Dokumenten über eine Graphstruktur, aber die Arbeitsergebnisse bleiben in einem universellen Format erhalten, das jeder nutzen kann
Für die meisten Elemente von Nino gibt es wohl breit akzeptierte Standards, und sie dürften sich leicht integrieren lassen; eine solche Garantie scheint also möglich
Self-Hosting könnte in der Einrichtung zu kompliziert sein, aber ich frage mich, ob ein Single-Tenant-Angebot helfen würde. Ob das auch für Privatnutzer sinnvoll ist, weiß ich nicht
Neben HTML und CSV gibt es auch eine JSON-Exportoption, und es werden weitere Formate unterstützt. In gewisser Weise ist es ein offenes Format (.json), aber dazu müsste Dokumentation ergänzt werden. PDF-Unterstützung soll irgendwann ebenfalls kommen
Auf jeden Fall eine sehr beeindruckende Arbeit, vermutlich nahezu von einer Einzelperson entwickelt, und es muss enorm viel Aufwand hineingeflossen sein
Als Feedback: Zuerst muss klar sein, wer die Kunden sind. Man sollte erklären können, wie ihr Tag aussieht und wie Nino ihnen hilft, Arbeit besser, schneller und günstiger zu erledigen
Man muss konkret zeigen, was ihre fünf größten Probleme sind und an welchen Stellen Nino klar besser ist als Konkurrenzprodukte. Wichtig ist, den Workflow zu zeigen
Ebenso sollte man zeigen, wo sie arbeiten, mit wem sie zusammenarbeiten und woran sie zusammenarbeiten, und Nino dabei direkt neben bestehenden Tools vergleichen, um zu zeigen, warum es besser ist
Schließlich darf man niemals unterschätzen, wie schwer es ist, Menschen dazu zu bringen, ihre heutige Arbeitsweise zu ändern. Wir haben nicht mehr 1990, und Menschen nutzen seit Jahrzehnten Tools zur Lösung von Problemen von Wissensarbeitern. Es braucht einen Grund, warum sie wechseln sollten
Ich bin mir nicht sicher, ob das „App-Chaos-Problem“ tatsächlich existiert. In den Unternehmens- oder Rollen-Workflows, die ich erlebt habe, gab es jeweils eine Kombination von Apps, die die einzelnen Use Cases gelöst hat
Als ich zum Beispiel in meinem früheren Unternehmen als Leiter Developer Relations gearbeitet habe, nutzten wir Atlassian-Produkte für interne Dokumentation und Aufgabenverfolgung, Google Docs und Sheets für gemeinsames Schreiben mit externen Teams und GitHub mit Markdown für den Build externer Dokumentation
Alles war zwar Text, aber die Workflows waren unterschiedlich, ebenso Anforderungen wie Berechtigungen, und am Ende haben wir für jede Aufgabe das passende Tool gefunden
Ich unterstütze diesen Versuch, hoffe aber, dass hier nicht nach „App-Chaos“, sondern nach einem konkreteren Problem gesucht wird
Glückwunsch zum Launch. Es sieht wirklich toll aus, und ich halte das App-Chaos-Problem von Produktivitätsarbeitern für ein reales und lösbares Problem
Ich baue selbst etwas Ähnliches. Ich habe damit begonnen, nachdem ich mehr als zehn Jahre lang täglich mehrere Apps in „risikoreicher“ White-Collar-Arbeit genutzt habe
Es ist noch früh, und der Ansatz ist etwas anders, aber es gibt Überschneidungen zwischen den beiden Visionen. Ich konzentriere mich auf eine kleinere App-Menge, mache die Funktionen dafür dichter und versuche, Funktionsparität mit etablierten Platzhirschen zu erreichen, während ich eigene Funktionen ergänze. Deshalb dauert es, bis es richtig umgesetzt ist
Ich bin gespannt, wie sich Nino weiterentwickelt, und würde mich später gern vernetzen, sobald ich etwas Vorzeigbares habe
Ich habe früher einmal etwas Ähnliches gebaut. Meins war webbasiert: https://github.com/GWBasic/ObjectCloud
Wenn ich meinem jüngeren Ich etwas sagen könnte, dann, mehr YC-Material darüber zu lesen, wie man ein Unternehmen gründet. Ich habe gebaut, wovon ich dachte, dass es gebraucht wird, hätte aber viel stärker anhand tatsächlicher Kundenbedürfnisse iterieren sollen
Das heißt: Ich hätte ein paar Kunden finden sollen, die eine enge Integration zwischen solchen Use Cases brauchen, und ihre Bedürfnisse die Umsetzung antreiben lassen sollen
Der Grund ist, dass es bereits viele Anwendungen gibt, die dasselbe leisten. MS Office, Google Drive usw. sind ausgereift, und der Markt insgesamt wird gut verstanden
Ich empfehle, ein paar Kunden zu finden, die durch geringe Interoperabilität zwischen drei oder mehr Anwendungen oder Use Cases ausgebremst werden, und sich auf deren Use Cases zu konzentrieren
Es wird mehr als 15 Jahre dauern, so ausgereift zu werden wie Produkte wie MS Office oder Google Drive, aber wenn man einen konkreten, dringenden Bedarf in einer bestimmten Nische löst, ist das den Kunden egal. Denn ohne dich können sie ihr Geschäft nicht betreiben
Sicherheit und Datenschutz sind schwierige Verkaufsargumente. Es interessieren sich weniger Menschen für eines von beiden, als man denkt, und bestehende Plattformen bieten deutlich mehr Funktionen, als die daran Interessierten gern zugeben würden
Außerdem klingt ein Pitch nach dem Muster „es gibt zu viele Tools“ wie ein instabiler Monolog. Die Behauptung, dass allein die Existenz vieler verschiedener Tools ein Problem sei, hält dem Gegenargument „Dann nutz sie eben nicht alle“ nur schwer stand; die Formulierung sollte daher besser geschärft werden
Besser wäre es, sich auf Komfort und Integration innerhalb der Plattform zu konzentrieren. Dort entsteht tatsächlich zusätzlicher Wert
Viel Glück
Beim zweiten Punkt hast du recht. Meine Formulierung war nicht gut. Danke für das Feedback