two learnings

There are two main learnings from working on Nodebook:

  • graphs of individual items don't work, but graphs of lists might work
  • graphs can be used only sometimes, mostly depending on the cadence of the use
    • highly aligned groups of people that visit their graph(s) very often
    • less coupled groups that don't visit graphs often, but still have a maintainer





lists learnings

  • multiple input and output connectors are awesome
  • users need more flexibility than just tables

rich text nodes

saw Linear's documents: https://x.com/linear/status/1786059513235177480

Can I extend that idea? Yes, yes I can.

RTE is the answer to composability in the UI. It's not so much about "writing text", but about inserting UI modules that you want for any given task.

Can we extend the idea of "inserting UI modules" to "inserting features"? Can we, as users, compose the app and the UI that we need to solve the task?

composable app features

I can insert functional pieces:

  • burndown chart and reports (/ + burndown chart)
  • fields and properties (/ + assignee or / + project)

Q: What kind of architecture do we need to extend this idea of composable UX to the entire app?

A: Composability is (also) then at runtime. Some sort of type system, components that know how to render certain types of inputs. Filtering based on interfaces ("give me all 'tasks' that are 'not done'"). Observers that can react to updates and changes. Materialzied views and automations.

This simplifies internal architecture - everything is of the same type, and you let the user compose the pieces.

Resemblance with Tana supertags and search nodes.

Data and schema are stable, and UI is then just "what the user picks". We can transclude and expose different functional features through different UI components, but still preserve the same underlying date.

We can switch components (from a list to a table).

Resemblance with Embark.