Seelabs for b-liner users

For a while I used b-liner almost every day. I used it for research, exploring new ideas, and quick and dirty scheduling. It fits the way I work. Since I'm mostly a Linux and Emacs user, I switched to using Emacs' org-mode many years ago. Seelabs takes what I liked best about b-liner and combines it with ideas from org-mode, GitHub, ProjectionLab (the app I use for financial planning), vim, and some ideas of my own.

Largest changes from b-liner

The biggest added functionality from b-liner is:

• timelines (including directly editing timelines)
• simulations for both scheduling and financial models
• dependencies for scheduling
• periods: a period is one slice of a model's timeline. It's useful for financial models where a node representing "liquid net worth" has different values over time, or a node representing "social security" has different values if the person is younger or older than 67 for the period
• scenarios ("what ifs")
• collaboration (including permissions on sub-trees and GitHub-style pull requests)
• fields instead of spreadsheets (fields are reactive. If you change a field value dependent fields automatically update)
• fields can optionally be displayed on a node, and different widgets can be used to display field values on a node (a "percent done" progress bar, for example)
• different formula model. Seelabs uses Python expressions and guards. A "guard" is used to let fields act differently for different periods, or act differently if a node has children or not

I tried to keep b-liner's main editing functions, but there's also a vim-like mode for interacting with the model.

Use cases

I'd like to use this for:

• Financial modeling. I'd like to use seelabs for what I'm currently doing in ProjectionLab.
• Scheduling, especially quick and dirty schedules like I used to do with b-liner.
• Summarize daily web sites into a tree for quick browsing without the temptation to spend too much time on the sites.
• Collaborative research. Start fleshing out a topic and let other people contribute by submitting PRs or just directly editing the tree (and using permissions to keep things sane).

Simple Navigating and Editing

I no longer have access to b-liner, so my memory of b-liner editing commands may be off. These are the fundamental commands to create and edit trees:

When you add a new node you'll immediately enter the node's headline.

The arrow keys change what the current node is.

The one non-b-liner key you'll need at this point is i. If you press i it will let you edit the current node's headline.

There's more functionality to introduce, of course. But those few commands will get you going and let you create simple outlines.

f is your friend

I'm a heavy keyboard user. Seelabs is designed so you can efficiently use it without ever touching the mouse. An important way this is done is with "hints". The f key is used for hints (f is your friend). It lets you quickly jump to any node or press any control. If you press f, each node will display a "hint" or short tag consisting of one or two letters. If you type the letters in a hint, it will set the current node to the node whose hint you typed.

f will also display hints next to controls. So it's easy to press buttons or select items in drop-down boxes using hints.

Hints can also be used to quickly cut any node, or add a child to any node, or paste a sub-tree as a child on any node. The way this works is almost all commands take the form of [count] operator target, where operator is usually a single character (e.g. d for cut). If you want to cut a particular node and it's not the current node, type df, then type the hint, and the node whose hint you typed will be cut. This works for almost all commands. z is the hide/show command. So zf lets you pick any node to hide/show the children. As an aside, typing the same letter twice usually means "act on the current node". So dd cuts the current node. zz hides/shows the current node (Tab also works). Working with a tree this way is similar to how vim commands work.

? shows every key available where you are, and u undoes anything.

There are also : commands, like in vim. Not everything is available as a visible GUI element right now.

It's very powerful, but of course, this is for power users. Using the mouse, arrow keys, and Ctrl-x, Ctrl-c, and Ctrl-v also work (and I'll make sure every : command is available on the GUI somewhere). While I don't expect many users to adapt to the [count]-operator-target workflow, I do hope users will still use f to quickly set the current node.

Fields

b-liner supported hierarchical spreadsheets. This was very powerful. Seelabs doesn't have spreadsheets. Instead, nodes can have fields. Fields can be literals, and common data types for scheduling and financial models are supported:

Fields can also be formulas. When adding a field, a field has one of three "value shapes": simple, rollup, and guarded.

Simple

A value or formula with no condition.

Rollup

A value computed from the node's children (sum, count, max, min, average, weighted average, custom formula), or the node's own value when it has no children.

Guarded

A list of conditional values; the first whose condition holds is used.

The formulas in seelabs are Python expressions. There's an embedded expression engine on the seelabs server (Starlark).

"Rollup" is how I usually used spreadsheets in b-liner. I had a task that I would break down into sub-tasks and the parent would hold the sum of the effort or cost of the sub-tasks.

"Guards" are used in many places in seelabs. They are really just a way to write cascading "if" statements.

You can add fields to a node by typing F to toggle the "fields" panel. This is where you can edit the fields on a node. You can also group fields into logical categories and assign permissions to groups of fields.

Display On Node

You can decide if a field's value should be visible on a node, and how the value should be displayed. Most of the time text will be used, but other widgets are available (progress bars, status boxes, checkboxes). Guards can also be used to display different widgets based on different conditions.

Node types

Once you assign fields to a node, you may want to give that node a type. For example, in a schedule you may have nodes that have fields for tasks (effort, predecessors), and you may have nodes for resources that have fields for department and hourly rate. When you add nodes to different parts of the model you want to add the right type of node. Node types let you do this. Nodes can restrict what types of nodes can be children, and you can define a default node type to be added if the user doesn't specify one (for example, task nodes add other task nodes as children).

Timelines

These are Gantt charts. For schedules, they know about dependencies and will draw arrows for the dependency. Most bars are editable and changes made to the timeline will be made in the tree model. For financial models, it's useful to view the different plots while looking at the timeline (both will use the same x-axis so it's easy to compare). This makes it easy to match up major events like "retirement" with changes to plots like "liquid net worth".

Simulations

Fields can have values drawn from a distribution. For example, in a schedule, a task may have an effort with an optimistic, pessimistic, and likely effort value. This will be modeled as a "pert" distribution. A simulation can then be run and all the fields that take their values from a distribution will be sampled and all the other dependent values re-calculated. These are then saved as distributions themselves. When many replications of this have been run, all the saved distributions can be viewed and conclusions drawn. For example, what is the probability a parent task will be done at a particular date? What is the date that I have a 90% chance that this parent task will be complete?

Simulations work the same way for financial models as well, but they are more computationally expensive because they need to simulate over many periods of time (financial model fields have a value per model "period").

Financial Models

There is some special functionality to support financial models. "Periods", of course. There are also currency data types (with currency codes - so if you own a house in Canada, it knows the value is in CAD and there's a way to convert to USD in the model). There are also functions that work with currencies so all the parts add up as an accountant would expect. For example, the "allocate" function would split $100 three ways as $33.34, $33.33, and $33.33; the "drain" function withdraws from accounts in order.

There is also a useful plot in financial models that shows a particular value over the model's period (typically "net worth" or "liquid net worth").

With simulations, you'll get a "fan chart" that shows a Field across the Periods. There's a line for the median outcome, and bands around it for less likely outcomes. You can also add "goals", such as "liquid net worth > 0" and see how often that goal is met during a simulation. There's also a plot of the distribution of the main value at the given period (e.g. "what's the simulation say the distribution of my net worth will be in 2045?"). Scenarios (what-ifs) can also be plotted against the main model.

Financial models can handle inflation and one-time events as well. There's a Claude skill called /lets-see-finance to design an initial financial model that you can then tweak yourself.

What-if Scenarios

Both schedules and financial models need to compare what happens if different choices are made. What happens if I buy a vacation house? What if I retire at 65 or 70? Should I refinance my mortgage or not? Hire now or next quarter? In seelabs each of those is a "Scenario" — a named alternative to your main model. A scenario holds just the changes that make it. Edit the main model and every Scenario follows along.

"Simulate all" runs the main model and every Scenario on the same random draws. This means every model sees the same crashes and booms and the only difference between them is the choice you're weighing.

Then it lines up each goal's chance side by side. For example:

You also have the option to accept a scenario to make it part of the main model.

More On Schedules

Seelabs is already a good tool for quick and dirty schedules, which is what I used b-liner for. There's some additional support for task dependencies, Gantt charts, and simulations. Critical paths, optimization, and constraint solving are partially complete.

Collaboration

There are two ways to collaborate. One is allowing live editing by everyone who has access to it. Permissions can make this reasonable. Permission can allow or deny reading or writing on a project, node, or group of fields. For example, salaries can be put in a group and most people could be denied access to the salary, but could still participate in estimating efforts in task breakdowns without seeing sensitive salary information.

The second way is GitHub-like pull requests. This works, but it's a little wonky right now (the live view doesn't quite fit with the model). How this works is people can submit "pull requests" to your project. This shows each change their model would make to the project. Users can comment on the differences. Finally, the project owner can decide to merge or close the PR.

Browser Extension

There's also a browser extension that adds the page you're reading as a node to the current node (or a pinned "target" node). This seems like a good way to easily add references for a topic and put it in a tree with all your other thoughts on that topic.

/lets-see

There is an interface to Claude Code called "/lets-see" with sub-categories for scheduling, financial models, and research.

Try It

There are read-only demo trees at:

• Financial model
• Schedule
• Research

Type ? for a list of key bindings (that page scrolls). Look at the timeline and simulation pages. And remember f is your friend.