Show HN: Bike – macOS Native Outliner (hogbaysoftware.com)
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
242 comments
[ 3.8 ms ] story [ 260 ms ] threadIn 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.
Shelf is really simple - the JS implementation is tiny (https://github.com/dglittle/shelf) and a walkthrough of the algorithm here is a quick read: https://bartoszsypytkowski.com/shelf-crdt/amp/
It wouldn’t handle character level sync - but would let you merge documents at a rows/items/blocks level.
So https://www.simperium.com/overview/ might be a low-effort option to add syncing without managing your own server.
> - Data transparently moves across mobile, web, and desktop versions of your app
> - Your users can read and write data even when they're offline
> - Multiple users can collaborate with the same data at the same time
> Simperium persists your data for you in buckets... Every Simperium object is JSON data that is stored in a bucket.
> Simperium does some basic conflict resolution for you automatically... When two edits are made for the same field though, Simperium supports automatic resolution for strings (currently) and will merge the two edits together.
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
But I think this animation is important. Bike is a "tool for thought". I think the way that it "feels/animation" is important. Bike's build built from the ground up to support this. Check out the movie or better yet try the download. Typing feels a bit smoother, text slides into place.
And yes it can be turned off. And no it doesn't slow you down, animations are canceled if you type again before they finish.
I don't have a Mac to try this on, but slides into place sounds like what Microsoft does in Outlook and I ended up turning it off.
Maybe it's not the same thing though. In Outlook (and some other Office programs) as you type the text seems to appear a little more slowly and the cursor glides to the right. To me, it always felt laggy and so I turned it off.
1. "Fluid" (smoothly animated) editing. You could argue it's not important, but this is something new and unique to Bike. Bike is a "tool for thought". I think how the app feels is an important aspect.
2. macOS native app, of course this is a plus and minus. But if you are on a Mac Bike will generally us a lot less resources then those apps and integrate better with the rest of the system.
3. Local files in open formats. Logseq has this of Course, but I think there's something pretty nice about having your outline just be simple HTML. Easy to parse, easy to work with, should be able to view and make sense of as long as web's around.
4. Faster. Bike is designed to work on somewhat big outlines. Moby Dick has been my test file. It opens instantly. I've just pasted that into Logseq and my computer is working hard a few minutes later. Not sure how workflowy does because it puts me over quotas.
Bike has a pretty unique foundation compared to other outliner apps. It's also missing a lot of higher level features that I plan to build out over time.
Also, when dragging-dropping, I found it way too easy to make empty nodes which was disconcerting.
However, I am looking at it now, and while it's a nice little app, it's not an outliner and I am not sure if I am going to be able to find any use for it.
Outliners are explained here: http://outliners.scripting.com/
Why are you comparing Logseq to one?
Do you think you could add support for pandoc to export to other formats and import things?
Another option --- possible to set it up so that each node is a text file (or other file format, see pandoc above) and they are grouped using file directories? The nifty Tombo notepad worked thus, and I found it really nice for keeping notes --- for bonus points, multiple files in a directory which have the same name would show as a single node, but have a toggle at the top to select which file extension one is viewing, w/ an option for "all" which expands them so that one can see all of them.
Maybe, but not likely soon. Bike does already provide read/write support for .bike (html subset), .opml, and .txt. I think best route is to work from those file formats.
> Another option --- possible to set it up so that each node is a text file (or other file format, see pandoc above) and they are grouped using file directories?
I've long wanted to try something like that. It would be very fun, but I don't expect Bike will do this.
If you do the Tombo.exe type thing, please let me know --- I'd be delighted to have something like that on MacOS.
There are other, equally basic for $0 or $10.
You only need to pay if you want to change some of the settings or use applescripts.
I might, after using it, find that it’s just too simple and I need an aircraft carrier after all, but my impression right now is that the Obsidian-vs-Bike comparison is not 1:1 enough to be fair.
A cargo bike perhaps, but if you call Obsidian an aircraft carrier already then there aren't much metaphores left for software which does way more and is (feels) slower than Obsidian.
Bike will also read/write .opml files. You should be able to share with iOS outliner that way I think.
Is there any way to change the font? As a developer, non-monospace fonts feel foreign for composing text.
That and ability to zoom in/out or increase/decrease font size.
I'm getting a lot of request for also adding changing the underlying font. Will likely add that sooner then later now since lots of people seem to need.
quick question: why you chose to go with HTML instead of making OPML the default file format? I'm not judging, I'm just curious.
Also (not sure this will happen, but I plan to try) I expect to add different node types. For example right now every node is a paragraph. In future might have ... A HEADING (innovation I know). Again that maps really well to HTML, not as well to OPML.
Plus I just like the fact that .bike files are HTML. Makes me confident that they will live and be readable far into the future.
For example, Dynalist use this idea for their files
And node itself is heading, while when they need paragraph with heading they create _note="" attribute into <outline> element
But for my own use I over time realized that was a mistake. All the parsing and formatting adds complexity. I think rich text (which to be clear Bike does not yet have, though I will add soon) is a simpler way to work from user perspective. Just issue commands instead of remember and see formatting rules. It's cleaner and simpler for my uses.
Anyway, congratulations on the impressive first public release. The more outliners the better in my opinion.
I think this format is fantastic for Show HN threads.
I do struggle to understand the value proposition though. I've been using Bear for outlining, admittedly smallish lists. It's macOS native, supports things like pasting in images, video, markdown, checkboxes, etc.. and is supported by a tiny subscription fee or free. I've never run into performance problems.
Some people just want to work on massive outlines with either text or links and nothing else, move those list items around frequently, and to those people $30 might be cheap. As a product it seems tricky to me, but I'd love to hear from anyone who's the perfect customer, and how this hits the mark for you. As in, what the hell do you plan day-to-day?
Also I quite like the icon, and the nature of it being incredibly simple. In a sense, it reminds me of the first version of IA Writer.
So value proposition... It's a unique surface for your ideas. The way that it "feels" is important and different than any other app. If that helps you think then Bike might be fore you.
In another comment I said Fluid = Animation... and it does, but there's another aspect of fluid with Bike. If you try most any outliner there are pretty rigid tools. A little hard to explain, but they don't feel "fluid" like a text editor. There are limits and constraints. Bike is different in that it has all the capabilities of an outliner, but it also has all the freedom of a text editor. You can select over multiple lines, cursor moves like a text editor.
Not sure that I've explained that last bit well... but try a good outliner like Workflowy. Then try Bike, beyond the animations (they can be turned off in preferences) Bikes core editing commands feel different.
[0] https://www.mindnode.com/
[1] https://reflect.app
Horses for courses I guess.
Bike looks neat though.
<spews out vitriol>
It's a tough balance. Software doesn't age like fine wine sitting on a shelf - it lives in a dynamic environment. It's more akin to produce that will rot over time. Even if no new features are added, it still requires maintenance - by someone.
Having said that, I’m not sure a subscription model makes sense for an app like MindNode, since I’d bet a majority of its users only work on mind maps sporadically That’s conjecture on my part, of course, and I could be absolutely wrong, but I suspect people who do everything with mind maps are fairly few and far between. Paying annually for Ulysses, a writing app I really do use every day, is one thing; paying for MindNode, which I use maybe once a quarter, is a big ask.
I am all for layers of features that cost money to unlock, but never ever ever on a subscription basis. It's like every developer out there heard that SaaS is where the money is at and decided that applied to their project out of dogma rather than a well reasoned business case.
https://apps.apple.com/us/app/bike-outliner/id1588292384?mt=...
Mac App Store version is subscription based. I know many people don't like that, that's why my direct download version is not subscription based... but for Mac App Store upgrades are a pain/impossible. So subscription.
This is a very cool idea. Might make note-taking a lot easier. I’m looking forward to trying it out.
I think you started working on this around the time I was working on multi-block text selection in Notion. I remember seeing a preview tweet in a Andy Matuschak thread and thinking “great minds!”. When I started working on it, I was so surprised that no outliner I tested had multi-item text selection! It’s a unique fusion. I’m curious about how you handled deletions across different indent levels… Do you know of any other outliners with it besides Bike and Notion?
Bike's editor is pretty much:
OutlinerLayer RowLayers LineFragmentLayers
I use CoreText to line break and render into each LineFragmentLayer. A whole new level of performance is possible if I knew more metal/opengl, but right now rendering text on CPU and sending as line fragments to CoreAnimation.
> Do you know of any other outliners with it besides Bike and Notion?
It's hard to define "outliner". This has been a main feature of TaskPaper for a long time... but TaskPaper is maybe a bit more "text editor" than outliner. Also tools like orgmode and probably lots more are pretty much outliners and also have all text editor features.
But yeah, for tools that feel more like an outliner it's not a common feature. In particular Bike even allows you too over indent and movies lines around without moving children. I think that's pretty unique, and goes together with multiline selection in Bike's case.
OmniOutliner feels like it has a separate text field for each node. Bike feels like a text editor when you're editing a document with nodes, which to me is more natural.
Just quickly clicking around makes it look like you are not working on it. It's explained, but it would be better to change some things around so it doesn't look completely dead. E.g.
> You can follow our daily progress / We share our progress daily and share everything, from code to finances.
> This is today's entry (Apr 28 '22).
It also gives false hope one could see the product in two weeks (which was a week ago).
I wanted a (preferably open-source) alternative which I could use with self-managed storage/sync without sharing any data and found Logseq to be pretty good.
I know that logseq also supports org files, but I am not well versed enough with org to comment how well it stacks up against emacs.
- "respects your computer's memory and battery"
- "uses open file formats"
- "is scriptable"
Feels like we should also think about these kinds of things when we think about "organic" software. Kudos to the developer for these.
https://arstechnica.com/gadgets/2007/10/mac-os-x-10-5/8/
Of note:
> [The] advent of Core Animation probably means that we'll have to endure some amount of gratuitously animated software created by "overly enthusiastic" developers. But the same was true during the introduction of styled text and color graphics. Mac developers learn quickly, and Mac users are good at rewarding restraint and punishing excess.
There’s a similar story around SwiftUI. It was initially created by the Apple Watch team at Apple, then extended to all the other OSes (all this was long before it was made public).
In Bike it's fast enough that when you scroll it just updates what you can see on the screen. This means you only pay memory for visible text. For most macOS apps scrolling performance is achieved by pre-rendering before and after the visible scroll area. So you pay for that cache and you also pay for the background processing required by pre-rendering.
Also consider simple things like window resize. In Bike that only effects visible text. If you open a large document in TextEdit you will see that resize is quite slow and processor and memory intensive. (you can test with https://www.hogbaysoftware.com/posts/moby-dick-workout/). And then after that resize there's lots of background processing to refill a bunch of layout caches I guess. On the other hand resize is instant and only does work for visible text in Bike.
I don't think the animations are expensive, but it's hard to test because that work happens in Mac OS window server and I'm not an expert there. If they really are a problem and you are on battery then you can turn off animations in preferences.