Interesting, Jesse, thanks for the feedback. I'd be happy to run these tests again – it's perfectly true that actually editing the middle of a very large document separates the sheep from the goats.

However, given the difference between the performance of my i7 MacBook Pro (now, alas, defunct) and the new M1-powered Mac, I do wonder if processing speed – but above all, OS optimisation – also makes a difference here. I'll check it out.

By the way: loved/still love FoldingText. Please, please refocus, produce equally nifty iOS app, make large fortune from outlinersoftware forum members ;-)

Cheers,
Bill

Jesse Grosjean wrote:

And just for a laugh, I opened the markdown version of the file (1.2 MB
>in size) in various markdown apps. Here's how they all did:
>
> ...
>
>Now granted I'm running these apps on a new MacBook Pro 14

This is interesting, but not my experience at all.

I'm on a 2015 iMac 27, maybe that's making a big difference, but
generally it still feels very fast.

I think you may not be doing the full set of tests...

Scrolling top to bottom, yes most apps can handle that OK. This is
because it gives the text system time pre-render and pre-layout. Same
thing if you resize the window or edit at the start of the document.

The problem, in my experience, comes when you scroll down into the
middle of the document and try things. I've just retested (macOS 12.3.1)
and I still see major problems:

1. Bear (good) – Best that I tested. I think they might also be
using a custom built text view. Maybe it doesn't matter for your
use-case, but I can't figure out how to really resize the window text
dynamically. Line width is fixed. Yes you can change global preference,
but that's not really what I mean when I say resize window. Also if you
do change that global preference while viewing test file you'll find it
very slow to update. Anyway I would say Bear passes test well, but its
text presentation is less flexible them I would like for a text editor.

2. ia Writer. I scroll half way down... I resize the window: It's very
rough, screen only updates maybe once a second. I type: There's a
noticeable delay. I type and there's a noticeable delay. I don't think
it passes, but it's better the next apps (for this particular test)

3. Nota. I start wonder if we are doing the same tests. Forget window
resize (which is the hard thing) if I type in the middle of a nota Moby
Dick document it takes multiple seconds before any text shows up.

4. Taio. Same story as nota. Typing is pretty much impossible in the
middle of the document.

I encourage a couple of other people to try these tests. Maybe my
computer really is just to slow, but I know when I do these things in
Bike on my computer things are instant.

Generally I use TextEdit to compare Bike against the default text
system. It performs better than the listed apps that I've tried (except
for Bear), but still has major problems. For example scroll to middle of
test document and resize window. For me that often loses my place. The
window resize also effects scroll position and I'm lost. Or other times
it saves my place, until the first time I click anyway to place my
cursor, then it scrolls off into nowhere land.

> You don't have to slim own your app to the
> point of having no real features at all to benefit
> from fast loading and scrolling (and editing, for that matter).

Bikes editor speed is independent from feature design choices.

> So what's his point? In short, what's the point of Bike (I've got some
very
>large outlines in Dynalist, and they don't slow down noticeably in any
>of the apps – even though they're markdown-compatible)?

My point is that I think outliners and text editors can be better than
they are. So I try to imagine it and then I try to build it.

Ah, see, that confirms the OS-specific thing. I've just taken a couple of moments to test Bear, iaWriter and Nota.

On my M1 machine, they're all more or less as fast as each other, even when I resize windows and enter new text half/three-quarters of the way down the file. No problems with iaWriter, nor with Nota (which is in beta in any case, but seems to run very nicely). There was a very, very slight delay when I first started typing text into iaWriter about three quarters of the way down the "book", but it didn't last and there were no further delays during the actual typing. The initial pause certainly wasn't long enough to cause any kind of awkwardness (maybe half a second). As you say, Bear was astonishingly fast – no sign of any pause whatsoever. But then, so was Nota.

I guess one of the big questions for Mac owners nowadays is just how long it will take before Intel-based machines cease being supported. I fear it's a kind of attritional process – after all, developers have no real incentive to keep updating their apps for both platforms; sooner or later they're going to focus on Apple Silicon. And Intel machines, alas, don't have the virtual resources which the M1 machines are capable of using to emulate an Intel environment.

On my M1 machine, they're all more or less as fast as each other...

I borrowed a M1 Mac (the first M1 MacBook Air) for testing.

Here's my experience:

First everything (including Bike) is choppy to scroll. Not terrible, but not "like butter", they are all missing frames. There are no big processes going on in background that I can see. I test for maybe 20 minutes, this behavior doesn't change. I come back after MacBook has gone to sleep, and now Bike (and other apps to different extents) scroll like butter. I don't know the cause, seems not directly related to Bike since it was effecting all apps.

---

Now that the slowdown is gone...

TextEdit: Scroll half way down. Resize window, definitely a different codepath here, resize IS fast... BUT it's also really buggy. I regularly get big blank areas in text view where there should be text when I resize. And after a resize clicking to place my cursor will reset the view position, for example: 1. Resize window. 2. (Assuming window hasn't become blank from first bug) Click on the word "Whale". 3. I end up in a different part of the document with "Whale" now scrolled off the screen. Resize is fast, but the above experiences are problematic to say the least.

iA Writer: Editing performance is better/good. Not as fast as Bike, but hard to notice delay. Window resize performance is still very slow, screen only updates every 0.5 to 1.0 sec or so. NOTE: Window resize test needs to be narrow enough that text wrap width is changing. Window resize is fast if text isn't being forced to wrap.

Taio: Faster, but still not very useable. Scroll to middle of document. Resize window is still very chunky. Text editing is also delayed, though certainly faster then on my iMac.

Summary: M1 is faster, but underlying text systems still leave lots of room for improvement. I don't understand how these tests could pass with a somewhat faster M1. I think maybe we are not doing the exact same tests. In particular text needs to wrap when you resize.

These tests might seem arbitrary. Why all the emphasis on scroll to the middle and resize text width? I think they are important to get right in any app, but essential to get right in an outliner. Anytime you zoom/focus/hoist you are performing this resize/scroll interaction.

With that in mind try Bike again with the Moby Dick document. Expand everything, use the Focus In / Focus Out shortcuts to navigate within the outline. Focusing into chapters or and individual items. It's all smooth like butter. There are no breaks or pauses. It's a different experience. This is why I built Bike and why I do the tests I do, because I'm trying to build this type of experience.

Also look at the amount of memory Bike is using, about the same as TextEdit. Look at the app download size, just a few MB. I'm trying to create something elegant and beautiful. Bike might not be the answer for you, but it's unique and does things that no other app can do.

---

So far all the reported Moby Dick tests have been with standard text editors, not outliners. Please use the .opml version to also test some outliners. Expand All, then navigate throughout the structure using Zoom/Focus/Hoist feature. Check RAM usage. I think you will see that Bike provides a unique experience.

Performance and fluid animations are just one aspect of what makes Bike unique. It's unique in other fundamental ways. For example Bike also has a full text editor mode and a full outliner editor mode. This is a fundamental building block for future features. No other outliner offers this combination.

Bike has other good fundamentals like open file formats, read / write of file format (not just export), scripting, standard document based architecture. Not all unique features, but a rare combination.

Jesse is running a special for Bike - post a picture of your hometown in response to this Mastodon post and he'll direct message you a coupon code to get Bike for $10 instead of the normal $30.

https://mastodon.social/@jessegrosjean/109404581663032742

I took Jesse up on his ten dollar offer. First impressions are very positive. I haven't tried the long file scroll test. For outline-sized files, it's working fine.

I'm hoping to replace OmniOutliner. It's great, but it's got quirks and OmniGroup is not going to be addressing them soon, if ever. I'm sure it will be supported for a long time. It's not exactly a vibrant product any more, though.

I think my primary use for it will be in conjunction with Devonthink. I'll write snippets that cover an idea in DT and then link topics in Bike to them. I've been brainstorming this way with MindNode. MindNode is nice and can be used in outline mode, but it's not quite the right tool for outlining.

The advantage to using an outline or a mind map as an overview of Devonthink topics is that I can discard an outline without discarding the ideas. Or, I can work up an alternate outline, recycling ideas.

The same could be done in Obsidian. Unfortunately, I seem to be a Devonthink recidivist. The tagging, replicants, and things like that just keep sucking me in.

Bike's formatting popover is really cool. I will probably create links with Keyboard Maestro more often than manually, though.

If I highlight a word in Bike, go to Devonthink and pick an item, my new Link to Bike macro will copy the DT item link and either paste it as a new link or replace the one that's already highlighted.

By the way, links that are just text with a separate link button is really nice for this sort of thing. There might be an argument for the link button taking up space, but the benefits are great. The text is more naturally editable.

Bike is a very nice tool.

It's certainly looking much more attractive now that it supports formatting!

I'm starting to suspect that CRIMPing may be strategic to the point of letting the rest of the world think it's crazy.

Obsidian is on a Windows box I'm cursed with for work. It's almost nice enough to make Windows fun. Methods championed by the Obsidian crowd have enhanced what I get out of Devonthink, too.

In Obsidian, I installed the Outliner plugin. Instead of writing extensive notes, I started adding links in the outline rows to note documents.

Back in Devonthink, I wanted to evolve my outlining. There are effective ways to outline, or at least block out a story, with groups and tags. Although perfectly workable, it's still not quite the fluid experience of a good outliner.

Links from an independent outliner to Devonthink notes works very well, pretty much like internal links from rows in an Obsidian outline.

Today it occurs to me Aeon Timeline could be much more of a planning tool than I've used it for.

Start with a blank timeline and a vague idea of a story. Go to the mindmap view and add story arcs for the major points you know you'll need. Exposition, rising action, final conflict, whatever. If you're obsessive, create arcs for each of three acts and make Exposition, etc., child arcs of the acts.

That yields containers to put events in, which don't have to be defined with dates and times. That can be filled in later.

Each entity has a URL field. That can link back to an Obsidian or Devonthink note. If you throw away the event in Aeon, the notes you made about it live on for later inspiration.

Being a Devonthink pedant, I should point out in that platform you can link to a note/document/file, or a group, or (very cool) a tag. If I put a link to a Devonthink tag in an Aeon URL field, I get a link to a constellation of notes for the event. The event notes, the note about the location, notes about the characters involved.

Of course, one can do the same thing with a map of content document in Obsidian.

The objective is to be free to erase in Aeon without losing work you might recycle in the future.

The trouble is, Obsidian is almost ridiculously competent at most things once you start exploring the many, many (often astonishingly good) plug-ins.

Outliner is brilliant – thanks for the tip (Drag-n-Drop Block isn't working very well for me at the moment, so Outliner's hot keys – while not perfect – are a useful substitute)

The various kanban board options (my current favourite: Cardboard) allow you to do the kinds of things you've been discussing with Aeon Timeline (an app I've tried to like, but find too fussy).

If you want to do more exotic things, you can install Dataview (and even DB Folder), which turn the whole thing into a (pseudo-relational) database.

LOL, this reminds me that I still have a Moby Dick MD file (1.2MB) that I used for similar testing. No fancy formatting other than headings for the titles.

It opens, reflows, and edits lickety-split on my iPhone XS Max (and of course my M1 MBA) with no discernible lag.

I second the kudos for FoldingText, I still use it as well. It handles Moby Dick very well too on M1, although a proper test for an M1 would probably be 20 Moby Dicks in a single file with inline images, tags, code blocks, and I don't know what else.

MadaboutDana wrote:

Interesting, Jesse, thanks for the feedback. I'd be happy to run these
tests again – it's perfectly true that actually editing the
middle of a very large document separates the sheep from the goats.

However, given the difference between the performance of my i7 MacBook
Pro (now, alas, defunct) and the new M1-powered Mac, I do wonder if
processing speed – but above all, OS optimisation – also
makes a difference here. I'll check it out.

By the way: loved/still love FoldingText. Please, please refocus,
produce equally nifty iOS app, make large fortune from outlinersoftware
forum members ;-)

Cheers,
Bill

Jesse Grosjean wrote:
>And just for a laugh, I opened the markdown version of the file (1.2 MB
>>in size) in various markdown apps. Here's how they all did:
>>
>> ...
>>
>>Now granted I'm running these apps on a new MacBook Pro 14
>
>This is interesting, but not my experience at all.
>
>I'm on a 2015 iMac 27, maybe that's making a big difference, but
>generally it still feels very fast.
>
>I think you may not be doing the full set of tests...
>
>Scrolling top to bottom, yes most apps can handle that OK. This is
>because it gives the text system time pre-render and pre-layout. Same
>thing if you resize the window or edit at the start of the document.
>
>The problem, in my experience, comes when you scroll down into the
>middle of the document and try things. I've just retested (macOS
12.3.1)
>and I still see major problems:
>
>1. Bear (good) – Best that I tested. I think they might also be
>using a custom built text view. Maybe it doesn't matter for your
>use-case, but I can't figure out how to really resize the window text
>dynamically. Line width is fixed. Yes you can change global preference,
>but that's not really what I mean when I say resize window. Also if you
>do change that global preference while viewing test file you'll find it
>very slow to update. Anyway I would say Bear passes test well, but its
>text presentation is less flexible them I would like for a text editor.
>
>2. ia Writer. I scroll half way down... I resize the window: It's very
>rough, screen only updates maybe once a second. I type: There's a
>noticeable delay. I type and there's a noticeable delay. I don't think
>it passes, but it's better the next apps (for this particular test)
>
>3. Nota. I start wonder if we are doing the same tests. Forget window
>resize (which is the hard thing) if I type in the middle of a nota Moby
>Dick document it takes multiple seconds before any text shows up.
>
>4. Taio. Same story as nota. Typing is pretty much impossible in the
>middle of the document.
>
>I encourage a couple of other people to try these tests. Maybe my
>computer really is just to slow, but I know when I do these things in
>Bike on my computer things are instant.
>
>Generally I use TextEdit to compare Bike against the default text
>system. It performs better than the listed apps that I've tried (except
>for Bear), but still has major problems. For example scroll to middle
of
>test document and resize window. For me that often loses my place. The
>window resize also effects scroll position and I'm lost. Or other times
>it saves my place, until the first time I click anyway to place my
>cursor, then it scrolls off into nowhere land.
>
>> You don't have to slim own your app to the
>> point of having no real features at all to benefit
>> from fast loading and scrolling (and editing, for that matter).
>
>Bikes editor speed is independent from feature design choices.
>
>> So what's his point? In short, what's the point of Bike (I've got
some
>very
>>large outlines in Dynalist, and they don't slow down noticeably in any
>>of the apps – even though they're markdown-compatible)?
>
>My point is that I think outliners and text editors can be better than
>they are. So I try to imagine it and then I try to build it.

Hm, now I'm working with the latest version of Bike in "anger", I'm actually quite impressed. There are a lot of subtle, well-thought-out features in here! Also, some steady development, which is great – long may it continue!

One of the nicest and most unexpected features is the ability to link to an individual row in an outline. This is very useful!

You can do the same thing in Obsidian, of course, but Bike does it very well.

Linking to a row, that's pretty neat - but how do you get back to the full outline?

I see that command click will open the row in a new tab. Is that the best use of links to rows?

Ah, yes, that's something that could usefully be added: a simple "Back" key somewhere in the top chrome (or maybe a "Back/Forward" key combination plus an "Up/Down" key combination).

But actually, it's easy, albeit keyboard-driven: you press Option+Cmd+Left Arrow (and can then press Opt+Cmd+Right Arrow if you want to zoom back into the same section of outline). It's well worth checking out the various keyboard shortcuts – this is very much a writer's tool. Ctrl+Cmd+Up/Down Arrow will, for example, move rows (or selections of rows, if you're in "Outline" mode) up and down.

Comparing (again) to Obsidian: Having misguidedly installed the "Outline" plugin in Obsidian so I could move rows up and down, I found that the relevant commands are actually built into the core plugins and can be assigned your keyboard shortcut of choice. I've removed Outline, which was in any case clashing with a couple of other elements and is much less flexible (the core plugin allows you to move any row, rather than just rows in lists).

One of the nice features of both Obsidian and Bike is that you can write multiple paragraphs of text in an outline, then turn any part of the text into a freestanding outline (in contrast to e.g. Dynalist, Workflowy, Zavala or OmniOutliner, all of which are based on outlines as the fundamental structure of the document). If you're drafting something, this flexibility is extremely useful.

The rich text support is much appreciated!

Amontillado wrote:

Linking to a row, that's pretty neat - but how do you get back to the
full outline?

I see that command click will open the row in a new tab. Is that the
best use of links to rows?

... what Bike could do with is support for tagging. That's because you can create very, very large texts/outlines in Bike, and having some way to zoom in on specific rows would be invaluable. I'm currently using my own informal tags and the excellent search function, but formal tag support would streamline this process considerably.

As would support for and automatic recognition of checkboxes (as tasks), in fact (essentially as "virtual tags"). But I'm sure something like that is on Jesse's roadmap.

(Aside to developer: I hope you have one, Jesse: I've been profoundly impressed and own several of your products, none of which you now develop! FoldingText was one of my favourites! But Bike is looking as if it may become an excellent replacement. Even more excellent with an iOS partner, but let's not count our chickens... ;-))

Oh, and the ability to export to OPML would be cool, too. Just sayin'!

Oh, and the ability to export to OPML would be cool, too. Just sayin'!

There is no "Export" menu, but there are already a few related options.

1. Bike can read/write OPML as a standard supported file format. When you first save a document just choose "File Format > OPML" in save dialogue.

2. Also even if you are using a different supported file format (.bike or .txt) you can always copy the selected text as OPML using menu Edit > Copy > OPML

3. And for the case where you want document format to be .bike, but you really do want to "export" entire outline to OPML file you can do that by: File > Duplicate and then when you save you'll again get option to choose OPML file format.

I think adding export menu items would mostly be redundant and would maybe encourage people to think that Bike could only export OPML instead of read/write it directly.

Ah, okay – I didn't spot the "Copy as OPML" option – that's cool.

Useful to know you can also save duplicate files in another format; also slightly unusual.

Thanks for that!

Rather impressed by the way internal links in Bike don't just refer to rows, but will also open other files. That is, if you've created a link to a row in another file, you can close that file, and if you then click on the link, the file will open again at the row you linked to. One of the neatest implementations of that I've seen, especially since the link format (URL) is very short. You can use an Apple-standard format if you wish, but the Bike-specific format is more efficient.

Nice one, Jesse!

+1 for tagging. Imagine you're writing a linear outline for a story with three plot threads. It would be nice to see the just the rows for Arc One, or Arc Two, or whatever.

The nicest thing about Bike is how easy it is to just write.

Rather impressed by the way internal links in Bike don't just refer to
rows, but will also open other files. That is, if you've created a link
to a row in another file, you can close that file, and if you then click
on the link, the file will open again at the row you linked to. One of
the neatest implementations of that I've seen, especially since the link
format (URL) is very short. You can use an Apple-standard format if you
wish, but the Bike-specific format is more efficient.

Glad you like the links implementation. More information on how exactly it works can be found here:

- https://bikeguide.hogbaysoftware.com/using-bike/using-links

Curious to know how Bike is better than OutlineEdit, for those of you familiar with both:

https://outlineedit.com/index.html

Thanks.

Steve

I would prefer not to describe such tools as "better" or "worse" than one another; the philosophy behind OutlineEdit is, I suspect, rather different from that of Bike, which is minimalist by design, although there are a lot of features lurking below the surface.

I haven't used the latest version of OutlineEdit, but much respect the developer's work – I did use the first version and liked it very much.

Personally, I found having a trial period for Bike was very helpful for evaluating it. OutlineEdit looks good, but the price is relatively robust. A trial would be cool!

Although having said that, I've just visited the website and doh! there is indeed a free trial! Silly Bill. I shall give it a whirl and see what happens!

Cheers!

Okay, having just had a quick play with OutlineEdit, I'd say the main difference between the two is that OutlineEdit is a true outliner – i.e., that's all it does. And it does it very well.

Bike, on the other hand, is a writing and note-taking tool, not just an outliner. By that I mean, you don't have to outline every paragraph (turn it into a bullet point); you can put as much white space into your outline as you like, and you can have multiple paragraphs at any level in the hierarchy. This makes it an exceptionally flexible writer's tool.

It also allows you to link rows, which is a neat trick (within files, but also between files, which is an even neater trick; and even between files which you then move around – which is definitely the neatest trick of all).

OutlineEdit has categories and checkboxes (although it takes the OmniOutliner approach to checkboxes, i.e. it's all or nothing, unlike e.g. Obsidian, where you can decide which rows have checkboxes and which don't). Bike doesn't have either of these things (yet).

OutlineEdit also has themes, for those who like these things (I'm all in favour of an elegant UI, but not particularly bothered by themes as such, although I have been known to fiddle with the ones in NotePlan).

OutlineEdit also has templates, which is a potentially useful feature. And supports graphics, which Bike doesn't do as yet (although you can drag and drop links to files, including graphical files, into Bike). OutlineEdit's support for graphics is very elegant, with full drag-and-drop importing.

They both allow you to create extensive outlines in any number of files, which is a pleasant change from being constrained to an Obsidian Vault (that's both a con and a pro in Obsidian, incidentally, in the sense that you can extensively customise each Vault depending on what you want to do in it). Again, Bike's slight advantage here is that you can link to individual rows in multiple external files and call them up with a single click. But maybe such a thing is on OutlineEdit's roadmap too.

For me, they're not directly comparable, because the underlying philosophy is different. OutlineEdit fits squarely into the Dynalist/Workflowy/Zavala category of apps. Bike is more akin to Obsidian or UpNote. They've both got "strengths" and "weaknesses" – but which is which will depend on what you want to use them for!

That's a quick resume for you!

I bought Bike as an outliner. I wish it had tag filtering, but I also like what MadaboutDana observed. Bike is more like an enhanced text editor that will support outlines.

Regarding tag filtering, by the time I'm reaching for that I'm probably looking for something like Devonthink or Obsidian to work with.

It would be nice. Not quite as critical as it seems, but nice.

I agree – it's not critical, but it would speed up certain kinds of action, especially in very large documents.

However, I've been experimenting and having some success with "microtags", by which I mean tags like :: or || or >>

Very quick to enter, very easy to search. If you don't need complex tag schemes (and if you're using a sophisticated outliner with a good search function, I'd argue you don't), microtags work well!

Amontillado wrote:

Regarding tag filtering, by the time I'm reaching for that I'm probably
looking for something like Devonthink or Obsidian to work with.

It would be nice. Not quite as critical as it seems, but nice.

Congratulations, Jesse, on being awarded a "Best App Runner-Up" award by MacStories. Very warm words were said about Bike (link here: https://www.macstories.net/stories/macstories-selects-2022-recognizing-the-best-apps-of-the-year/

Worth mentioning here, following my earlier comparison, that both Bike and OutlineEdit are very efficient apps. In this age of oversized, Electron-based apps, it's really nice to find highly functional apps with a minimal footprint. The same applies to Zavala, actually, as well as Notebooks and anything/everything programmed by the wonderful developer of Growly Notes.

A suggestion for you, Jesse, following my irritating experiences in e.g. Obsidian and various other folding outliners:

It would be very useful if one could put a top-level divider (nice, elegant slim line) below a folded section, and if the folding from the "parent" of that section went down as far as the divider, but left the latter visible. Let me explain:

Most (all?) outliners currently fold dividers into the text immediately above them. If you're a pedantic b*st*rd like me, this means you get a whole column of folded headings which can be difficult to group or differentiate. If, on the other hand, one could insert a top-level divider which would be left untouched by the folding, you could use such dividers to group sections together, or simply differentiate them more clearly.

I don't know if I've explained that very well, but would be happy to give it another go!

MadaboutDana wrote:

Most (all?) outliners currently fold dividers into the text immediately
above them. If you're a pedantic b*st*rd like me, this means you get a
whole column of folded headings which can be difficult to group or
differentiate. If, on the other hand, one could insert a top-level
divider which would be left untouched by the folding, you could use such
dividers to group sections together, or simply differentiate them more
clearly.

Aren't there two issues here?

One is the prevalence of markdown folding to headers, with nothing more. It's sufficient for most people. That's the case with Obsidian which isn't an outliner.

Two is simply a decision by outliner apps.
Workflowy and Dynalist will both fold to the higher bullet, but also have the option to always show the first line of any note. That option could be for more lines, but having a definable marker would presumably come with a performance cost.

WriteMonkey 3 takes a third way. I don't remember a fold marker as such, but its folding is infinitely responsive manually. A property of its json format, I assume.