Show HN: Bike – macOS Native Outliner

Bike’s most original feature is the “fluid” text editing. Lots of text editors have animated some interactions (cursor movement, insert newline, etc), but I think Bike is the first designed from the ground up to support fluid editing.

Give it a try, it feels different. (movie on home page if you don't have Mac)

Other Features:

• In text mode Bike works like a normal text editor. In outline mode rows are constrained to outline hierarchy.

• .bike file format is HTML subset, so files are easy to parse and manipulate. Bike also supports .opml and .txt.

• Scriptable via AppleScript. Javascript plugin API also expected in future, though no timing on that.

• Architecture needed to support fluid editing also makes Bike faster/more scalable than most (all?) outliners and many text editors. I test performance using the Moby Dick Workout[^1].

Implementation Notes:

• View is built using CALayers[^2].

• Animations are performed by Core animation and Motion[^3] lib.

• View performance is determined by visible text, not document size.

Model representation is interesting in that it’s just a flat list of rows. Each row has a `level` property, outline structure is determined dynamically. View implementation requires that each row has a unique ID.

I’m using OrderedDictionary from Swift Collections[^4] to store rows. This is Bike’s performance bottleneck for large outlines. Eventually I may change to augmented b+tree and then should be able to work with gigabytes worth of outline. That will be fun, but not sure it’s actually needed. Already probably fast enough for 99% of use cases as is.

Hope you find Bike interesting. I’m happy to answer any questions.

[^1]: https://www.hogbaysoftware.com/posts/moby-dick-workout/

[^2]: https://developer.apple.com/documentation/quartzcore/calayer

[^3]: https://github.com/b3ll/Motion

[^4]: https://github.com/apple/swift-collections

Show HN: Bike – macOS Native Outliner
hogbaysoftware.com

Sorry that's not likely. I'm a single developer, not ready to run a server. More likely (though still have many more basic features on roadmap) is automatic merging support when a Bike file is stored on something like Dropbox.

In fact that would be a pretty great service (for someone else to develop). "Dropbox", but for strutted data (xml, json, whatever) that knows how to merge trees and make use if unique ids. Maybe it wouldn't work, each merge situation needs a special case solution. But for Bike files at least I think it might work pretty well.

First, I use and love TaskPaper so I'm interested in what you've got going on. But on its surface, I don't see the differentiation between the two products right now other than Bike having slicker rendering and TaskPaper having more utility. It seems like TaskPaper is a competent outliner that supports focus and other features just fine. Can you comment to what the goals are that separate them?

Early in Bike's development I did try a few solutions, but I want Bike to work on somewhat big files. See (https://www.hogbaysoftware.com/posts/moby-dick-workout/). Anytime I loaded such a file into a sync solution everything blew up.

I've written about Bike's relationship to TaskPaper here:

https://support.hogbaysoftware.com/t/how-does-bike-relate-to...

I think core summary is:

1. Wanted to control own text editor. Building off NSTextView was limiting 2. Wanted to use structured document format. Plain text was limiting